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COMO LER ESTE LIVRO 


Do começo ao fim! Este é um livro curto e prático. Conforme o próprio 


título diz: Direto ao Ponto. Logo, você o deve lertodo, e na sequência. 


O livro está estruturado em três partes: contexto, receita e apéndices. 


PARTE |- CONTEXTO 


O contexto é formado pelo prefácio e pelos capítulos Produto mínimo 


viável e Inception Enxuta. 


O prefácio fornece o contexto sobre as influências que me levaram a 
escrever este livro. E muito importante tê-lo em mente para compre- 


ender a minha visão sobre o assunto. 


O livro se baseia no conceito de MVP, em inglês Minimum Viable Pro- 
duct. O capítulo Produto mínimo viável apresenta tal ideia com o seu 
histórico e a minha visão sobre o tema, bem como a evolução de pro- 


dutos enxutos. 


O capítulo de Inception Enxuta explica em detalhes o formato de 
workshop colaborativo que vai ajudá-lo a entender, alinhar e planejar 
o produto enxuto a ser construído. Talvez seja o início de um projeto 
ágil em uma grande corporação, ou o alinhamento sobre o que cons- 
truir em uma pequena start-up. O estilo colaborativo e dinámico da 


Inception Enxuta é o segredo do chef desta receita. 


PARTE Il- RECEITA 


Direto ao Ponto é uma receita, uma sequência de atividades colabo- 
rativas e dinâmicas que gerarão o canvas MVP, uma representação 
visual do plano de criação e evolução do produto enxuto. Todos os 
passos desta receita estão detalhados seguindo a ordem dos capítu- 
los, começando pelo capítulo 3 — O produto e terminando no capítulo 


8 — Calculando esforço, tempo e custo, 


PARTE III- APÊNDICES 


Um livro com título Direto ao Ponto obriga o autor a fazer uso do 
apêndice. Considero todo o conteúdo do livro essencial, entretanto 
ficou no apêndice o que foi acrescentado com o tempo, baseado no 


feedback dos leitores. 


Apêndice A traz um exemplo real do entendimento e planejamento 
de um produto enxuto a partir da receita Direto ao Ponto aplicada em 
uma Inception superenxuta: realizada em apenas seis horas! Alguns 


leitores me relataram que primeiro leram este apêndice (disponível no 


meu blog e na revista InfoQ) e depois leram o livro a partir do início. 
Os apéndices B, C, D e E fornecem, respectivamente, o glossário dos 
termos do livro, uma classificação sobre os níveis de competência do 
facilitador, um detalhamento sobre a agenda burn-up, e algumas ati- 


vidades quebra-gelo. 


Boa leitura e seja bem-vindo ao grupo dos facilitadores Direto ao 


Ponto. 


PREFÁCIO 


Neste livro, compartilho uma receita: uma sequência de atividades 
rápidas e efetivas para entender e planejar a criação de produtos 
enxutos, baseadas no conceito de produto mínimo viável (em inglês, 


Minimum Viable Product, MVP). 


Venho utilizando e compartilhando-a desde 2010 e percebi que, 


quanto mais o fazia, mais pessoas interessavam-se pelo assunto e 





retribuíam, compartilhando os seus resultados. O desfecho é este li- 
vro, que agora está fundamentado na experiência prática de muitas 
empresas (de startups a grandes corporações) e pessoas interessa- 


das em criar e evoluir produtos de forma enxuta. 


Como sucesso de tal receita, resolvi parar e refletir sobre o caminho 
que me levou a criá-la e, consequentemente, conceber este livro. 
Olhando para minha própria linha de tempo profissional (de 2000 
até 2015). destaquei os três principais movimentos que julgo terem 
influenciado na criação de ambos: Lean startup, métodos ágeis e 


design thinking. 
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De 2000 a 2007, vivi no Vale de Silício, na Califórnia (Estados 
Unidos), trabalhei em seis diferentes startups, e tive contato 
com inúmeras pessoas de várias outras. Nessa época, senti 
na pele o longo ciclo para criação de produtos, mesmo nas 
startups, e esse sentimento acabou afastando-me delas. Virei 
consultor e passei a trafegar por grandes corporações. Toda- 


via, segui como expectador e torcedor do movimento Lean 





startup, o qual culminou com Eric Ries publicando seu incrive 


livro, The Lean Startup. em 2010. 


Desde 2000, tenho utilizado (e abusado) de metodologias 
ágeis. A minha primeira sessão em uma conferência inter- 
nacional foi na Object-Oriented Programming. Systems, Lan- 
guages & Applications 2000 (OOPSLA), na qual apresentei 
o resultado de minha tese de mestrado sobre Orientação a 
Objetos e design patterns. Lá, tietei Kent Beck por admirá-lo 
na questão de design patterns e acabei comprando seu livro 
recém-lançado, eXtreme Programming explained. Assim, deu- 
-se início um caminho sem volta: estava exposto e infectado 


pela primeira de muitas metodologias ágeis. 


Em 2006, entreina ThoughtWorks e fui apresentado a brilhan- 
tes agilistas (Martin Fowler, Jez Humble, Jim Highsmith, dentre 
vários outros). Lá, usei e divaguei sobre metodologias ágeis, 
como: Lean, Scrum, Kanban, continuous delivery etc. Depois 
de alguns anos aplicando métodos ágeis, meu entendimento 
foi além de práticas e ferramentas — princípios e valores co- 


meçaram a ser naturais a mim. 


Fui pela primeira vez apresentado para design thinking vários 
anos atrás, por Jeff Patton, e foi na ThoughtWorks que tive a 
oportunidade de trabalhar com ele. Fiquei impressionado com 
sua habilidade de conduzir reuniões e atividades colaborati- 
vas e visuais. Aprendi e utilizei atividades sobre personas, jor- 
nadas de usuários e mapeamento de história. Hoje, entendo 
que fui influenciado e segui utilizando ideias e práticas que 
foram denominadas design thinking. Isso explica (e muito) o 
estilo colaborativo e visual que adotei como ferramental bási- 


co em meu trabalho, que fica evidenciado neste livro. 
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PRODUTO 
MÍNIMO 
VIÁVEL 
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Produto mínimo viável (em inglés, Minimum Viable Product, MVP) é 
a versáo mais simples de um produto que pode ser disponibilizada 
para a validação de um pequeno conjunto de hipóteses sobre um 


negócio. 


Basicamente, você não quer desperdiçar tempo, dinheiro e esforço 
construindo um produto que não vai atender às suas expectativas. 
Para isso, é preciso entender e validar as hipóteses sobre o negó- 
cio. O MVP ajuda nessa validação e no aprendizado da forma mais 


rápida possível 


Seu objetivo é somente a validação do primeiro passo do produto mi- 
nimo, bem menos elaborado do que sua versão final, o que é bem 
diferente quando comparamos com produtos criados da forma tradi- 
cional, que normalmente têm um período longo de criação de protóti- 
po, de análise e de elaboração. O MVP foca no produto mínimo, mas 
que já é viável para verificar se o direcionamento está correto; ou seja, 
o conjunto inicial de funcionalidades necessárias para o processo de 


validação de hipóteses e aprendizagem sobre o negócio. 


ORIGEM 


A ideia de MVP está originalmente vinculada aos conceitos populariza- 
dos pelo estilo Toyota de manufatura enxuta (WOMACK, 1990, 2003; 
OHNO, 1988). Steve Blank (2006), um empreendedor do Vale do Si- 


lício, criou uma metodologia baseada no desenvolvimento do cliente. 


Este foi o início do movimento Lean Startup, o qual teve seu ápice com 


Eric Ries (2011) e o lançamento de seu livro de mesmo nome. 


Acredita-se que Eric Ries popularizou o MVP a partir da publicação 
de sua obra. Entretanto, o termo já estava em uso vários anos an- 
tes do surgimento desse movimento, especialmente entre as star- 
tups com seus empreendedores e investidores do Vale do Silício. A 
expressão Minimum Viable Product apareceu pela primeira vez em 
2000 em um artigo de Willian Junk (2000), de título O equilibrio 
dinámico entre custo, cronograma, recursos e qualidade em projetos 


de desenvolvimento de software, em portugués. 


INCREMENTOS DO MVP 


MVP náo significa que o produto náo vá evoluir e incrementar suas 
funcionalidades: muito pelo contrário, sua ideia é o incremento va- 
lidado e guiado pelos resultados iniciais. A correção ou a confirma- 
ção do curso é que guiará os incrementos a seguir. Incrementos, 
estes, que são MVP: novos produtos mínimos adicionados aos pro- 


dutos mínimos já validados. 


Mais uma vez: produtos mínimos, mas, ao mesmo tempo, viáveis 
para fazer novas verificações sobre seu direcionamento. O produto, 
agora, é mais elaborado, talvez com uma base maior de usuários, 
permitindo validar novas hipóteses ainda mais aprimoradas. É muito 


importante compreender que o MVP promove uma criação evoluti- 
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va. Logo, a arquitetura, bem como o ferramental da construgáo do 
produto, devem permitir essa característica de evolução gradual e 


contínua. 


Em 2010, Jez Humble e David Farley (2010) publicaram o livro Conti- 
nuous Delivery. no qual elaboram sobre um processo de entrega rá- 
pido e de baixo custo, permitindo a criação incremental de produtos 
de software. Eles definem Continuous Delivery (em português, Entre- 
ga Contínua) como uma disciplina de desenvolvimento de software 


que promove entregas mais rápidas e com maior frequência. 


Apesar de o livro entrar em detalhes sobre produtos de software e 
o fluxo de trabalho para sua criação, a essência da ideia de Entre- 
ga Contínua é a mesma que Eric Ries recomenda em seu livro Lean 


StartUp: ciclos rápidos para validação das hipóteses. 


Ciclos rápidos e frequentes permitem tempos de liberação muito 
curtos e com baixos custos de experimentação. Porém, não é fácil 
implementar esse tipo de abordagem, já que os criadores de produ- 
tos no estilo MVP precisarão de estruturas e práticas diferentes da- 


quelas utilizadas tradicionalmente para produtos com um ciclo lento. 


Este livro tem o foco em atividades de análise e planejamento efe- 
tivo baseado em MVP. Continuous Delivery é a bíblia para entender 
o ferramental necessário para produtos de software; mesmo que, 
para outros tipos de produto, ainda devam-se aplicar as técnicas e o 


aprendizado compartilhado pelos autores Jez Humble e David Farley. 


PEQUENAS HIPÓTESES, 
GRANDES NEGÓCIOS 


O produto é construído de forma incremental com MVPs recém- 
-criados sendo adicionados ao produto consolidado já existente. A 
entrega contínua e incremental proporciona o aumento do valor do 
produto ao longo do tempo, enquanto que o processo de criação de 


produto tradicional não fornece qualquer valor até o final, quando 


ele todo está pronto. 


Ex” 


Vocé precisa ganhar altura? Subiria um degrau para isso? 


A E 
—~— 


E: 


Você precisa ganhar mais altura? Subiria mais um degrau para isso? 
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aT i 


A 
RF) 


Você precisa ganhar ainda mais altura? Subiria outro degrau para isso? 





LA 
E 


EMCONSTRUÇÃO 


VOLTEEM BREVE 





Você precisa ganhar mais altura? Espera a construção de um elevador? 





Resultado final: para subir, use a escada ou o elevador! 


Esta sequéncia de figuras mostra como MVP oferece pequenas vali- 
dações ao longo do tempo, enquanto o estilo de criação do produto 
mais tradicional só oferece a validação do todo no final. Mas, por 
favor, não se atenha a tal exemplo, pois os passos para validação 
de hipóteses dificilmente serão tão simples como um degrau após 


outro degrau relativamente parecido. 


À imagem ao lado oferece 
outro exemplo de produto 
mínimo viável: o MVP para 
atravessar um rio. Uma solu- 
ção simples para atravessar 
um pequeno riacho é colocar 


uma viga de madeira conec- 





tando as margens. 


Uma ponte muito simples 


Isso é um excelente exemplo de MVP. Além de permitir a travessia, é 
uma maneira simples para validar o local para a construção de uma 
ponte. Coloque algumas vigas de madeira em diferentes locais do 


riacho, e daí verifique qual delas é a mais utilizada para o cruzamento. 


O MVP promove uma abordagem incremental, na qual apenas uma 
pequena parte das hipóteses gerais são tratadas ao mesmo tempo. 
Cada uma delas é projetada, criada e preparada para ser adiciona- 
da ao produto e gerar dados úteis para a tomada de decisão, apren- 


dizagem e validação de ambas. 
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Em essência, uma ideia (ou grandes hipóteses de negócio) é se- 


quenciada em uma série de hipóteses menores, mais simples e, 


logo, mais fáceis de entender. Como resultado, elas são elaboradas 


mais rapidamente e disponibilizadas no produto para o usuário final. 


Por exemplo: se houvesse uma ponte neste local, quantos pedestres 


a usariam por semana? 


Nesse caso, o usuário final (ou quem valida o MVP) fornece dados 


para a validação do incremento do produto. Isso é essencial por 


duas razões: 


Correções e mudanças podem ser feitas em 
um estágio inicial do produto, em vez de só 
aparecerem no final da concepção, reduzin- 


do, assim, seu risco; 


A complexidade de análise das hipóteses é re- 
duzida, e os idealizadores do produto e o usu- 
ário final têm acesso antecipado a algo fun- 
cional e viável. Dessa forma, as decisões dos 
próximos passos e seus incrementos são ba- 
seados no próprio produto, em vez de serem 
hipóteses sobre outras hipóteses. Esse padrão 
de trabalho permite a construção de produtos 
bem elaborados, com passos pequenos, po- 


rém bem fundamentados. 


UM EXEMPLO DE EVOLUÇÃO 
VIA MVP 


O produto é construído de forma incremental com MVPs recém- 
-criados, sendo adicionados ao produto já existente e consolidado. 
Se o MVP recém-produzido foi liberado e tem um resultado positivo, 
a equipe segue seu plano de evolução e cria o próximo conjunto de 


features para o produto. 





MVPs para cortar grama 
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Essa figura mostra como MVP oferece validações pequenas 
ao longo do tempo, ao passo que a forma tradicional de 


criação de produtos só o validaria em sua versão final 


Por exemplo, o trator cortador de grama (MVP 8) representa 
o produto final e o tesourão de cortar grama é o primeiro 
MVP. Existe alguma grama para cortar? Existe alguém para 
lidar com um aparelho de cortar grama? A validação das 
hipóteses conduz a evolução do produto para o próximo 
MVP. Talvez, algo mais conveniente: um aparelho de cor- 
tar grama com um cabo. E se tal aparelho tivesse rodas? E 


assim por diante, até que o produto evolua de MVP a MVP. 


A validação mais importante, apesar de indesejada, é a res- 
posta negativa. Existe alguma grama para cortar? Não. Em 
tal caso, o tesourão não vai ser usado. E digo mais, um ex- 
celente (e caro) trator de cortar grama também não o seria. 
A hipótese é falsa; portanto, um produto totalmente evolu- 


ido teria sido um grande desperdício de tempo e dinheiro! 


Esse exemplo ilustra como o mínimo produto viável pro- 
move uma abordagem gradual em que apenas uma pe- 
quena parte de uma ideia mais abrangente é tratada na- 
quele tempo. Cada um desses MVPs é concebido, criado 
e preparado para ser adicionado ao produto. Em essência, 
uma ideia do produto é sequenciada em uma série de va- 
lidações menores, mais simples e mais fáceis de se enten- 


der, criar e validar. 


Vale a pena lembrar que, felizmente, produtos de software 
náo sáo manufaturados. No mundo do software, um trator 
de cortar grama pode ser criado por meio da adigáo de 


rodas, volante, motor e cadeira a um tesouráo. 
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INCEPTION 
ENXUTA 
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Projetos ágeis colocam ênfase nas entregas antecipadas e contínuas 
de software com alto valor de acordo com os objetivos do negócio e 
com as necessidades dos principais usuários. À criação do produto 
enxuto promove a liberação incremental do MVP — a versão mais 


simples de um produto que pode ser disponibilizado para o negócio. 


Mas como entendemos o MVP e começamos um projeto ágilo mais 
rápido possível? Como garantimos que a equipe comece a criação 


do produto com um bom alinhamento inicial e um plano eficaz? 


O QUE É UMA INCEPTION 
ENXUTA 


Em uma única semana de trabalho colaborativo, a equipe vai enten- 
der os objetivos do produto, seus principais usuários e seu escopo 
funcional de alto nível de uma forma que a duração do projeto possa 
ser estimada e uma 
estratégia de lança- 
mento incremental 
de MVPs possa ser 
identificada. 


Colaboração durante a 





Inception Enxuta 


Durante a Inception Enxuta, sáo realizadas atividades dinámicas 
para definição dos objetivos, das estratégias e do escopo do pro- 
duto, bem como o mapeamento e a priorização das funcionalida- 
des desejáveis para serem entregues gradualmente, construindo os 
MVPs. O principal objetivo do workshop é fazer com que a equipe 
descubra e compreenda coletivamente o que vai ser desenvolvido. 
Ao seu final, o time deve estar mais entrosado e com uma visão mais 


clara do caminho a seguir. 


DIRETO AO PONTO, 
A TÉCNICA 


Direto ao Ponto é uma técnica que ajuda a entender e a planejar a 
entrega incremental de MVPs. Ela organiza ideias e recursos em um 
modelo que busca compreender a principal finalidade do produto 
ao considerar as jornadas de seus usuários, para realizar as entre- 
gas incrementais de produtos viáveis. Como um livro de receitas que 
contém uma sequência de atividades rápidas e eficazes. a técnica 


vai permitir que a equipe: 
Descreva a visão do produto; 
Priorize os objetivos do produto; 


Descreva os principais usuários, seus perfis e suas necessidades; 
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Entenda as principais funcionalidades: 


Compreenda os níveis de incerteza, esforço e valor de negócio por 


funcionalidade; 
Descreva as jornadas mais importantes dos usuários; 


Crie um plano de entrega incremental do produto, impulsionado 


pelo conceito de MVP; 
Estime o esforço por amostragem: 
Calcule os custos e especifique datas e cronograma de entrega. 


As seções a seguir exploram conceitos fundamentais para a Incep- 
tion Enxuta, enquanto os próximos capítulos detalham as ativida- 


des que alcançam cada uma dessas ações. 


COLABORAÇÃO 


Colaboração é o ato de trabalhar em conjunto para fazer uma tare- 
fa e alcançar objetivos comuns. O sucesso de uma Inception está 
diretamente ligado à capacidade do grupo envolvido em colabo- 
rar efetivamente em cada atividade descrita neste livro. A Inception 
propõe um processo colaborativo de descoberta e esclarecimento 


em que as pessoas envolvidas trabalham juntas em uma sequência 


de atividades, com o objetivo de compreender opções e elaborar 
MVPs. As práticas apresentadas nos capítulos seguintes represen- 
tam métodos estruturados de colaboração, buscando um ambien- 
te criativo com partilha de conhecimento, aprendizagem e cons- 
trução de consenso. Elas visam aumentar o sucesso da equipe e 
melhorar como ela envolve-se no esclarecimento e na resolução 


de cada passo na direção ao MVP. 


DIVIRTA-SE COM 
QUEBRA-GELOS 


Nunca subestime o poder da diversão. Por meio do divertimento e 
do riso, seus níveis de estresse diminuem significativamente e você 
estará muito mais aberto a trabalhar com outras pessoas. Quando 
você está feliz e relaxado, está muito mais receptivo para tentar coi- 
sas novas e, assim, aumentar a sua participação nesse workshop 


altamente interativo: a Inception Enxuta. 


Pessoas altamente envolvidas, participativas, contentes e ativas nas 
atividades colaborativas: com isso em mente, você precisa quebrar 
o gelo e elevar o estado de espírito dos participantes. Quebra-ge- 
los ajudam a criar um ambiente amigável e tornar as pessoas mais 


confortáveis para participar das atividades. 


Elas são rápidas, divertidas e podem ser executadas para aquecer 
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a equipe e promover sua interação. São excelentes para se começar 
qualquer tipo de reunião do grupo, e ainda mais valiosas para os 
estágios iniciais de suas formações, quando as pessoas pouco se 


conhecem, o que tipicamente é o caso para Inceptions Enxutas. 


Você deve selecionar uma atividade quebra-gelo coesa para o mo- 


mento em questão. Nos primeiros dias, eu recomendo exercícios 





que se concentrem em compartilhamento de informações, tais 
como nomes e hobbies. Já após o almoço, você deve selecionar um 
para despertar as pessoas. Finalmente, você também deve conhecer 


os quebra-gelos que ajudam a transmitir mensagens simples, como 








"sistemas complexos são difíceis de lidar”, ou “documentação escrita 
não é o suficiente”. Além de serem divertidos e enérgicos, eles co- 


municam ideias importantes. 


Segue um exemplo de quebra-gelo bom para compartilhar nomes. 


No apêndice D você encontrará mais atividades e ideias. 


PAULO PONTUAL 


Esta é uma atividade rápida para ajudar os membros da equipe a 


lembrarem os nomes uns dos outros. Como funciona: 


Solicite aos participantes para pensarem em 
um adjetivo que comece com a mesma letra 


de seus nomes; 


© Forme um círculo e peça para cada participan- 


te dizer seu nome com o adjetivo, um de cada 


vez (Oi eu sou o Paulo Pontual!”; 


CD Depois que todos falarem, peça para que, em 


sentido horário, falem o nome e o adjetivo da 


pessoa ao seu lado; 


E) Depois de algumas voltas, pega que os parti- 


cipantes repitam o passo 3, agora no sentido 


anti-horário. 


Além de darem algumas risadas e quebrarem o gelo, essa atividade 
também ajuda a equipe a associar os nomes das pessoas a algum 


adjetivo, o que torna mais fácil lembrá-los. 


COLOCACÁO 


Não subestime o valor da interação face a face. Tecnologias ino- 
vadoras, como videoconferéncia e documentos compartilhados, fa- 
cilitam o trabalho remoto entre as pessoas. No entanto, durante a 
Inception, essa interação possibilita o árduo trabalho nas atividades. 


Éa garantia de que todos estaráo presentes e participativos. 


Quando todos estão na mesma sala, o nível de participação aumen- 


ta. Você não pode simplesmente sentar-se em um canto e virar as 
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costas para a reunião e fazer uma outra tarefa. Reuniões face a face 


tendem a ser mais curtas e eficientes do que as remotas. 


Entendimentos e desentendimentos são mais bem compreendidos 
e as expressões faciais e corporais somam-se à comunicação escri- 
ta e verbal. No geral, reuniões desse tipo ajudam a equipe a chegar 


ao ponto, direto ao ponto! 


A sequência de atividades para alcançar o MVP é extensa. A cola- 
boração e os resultados obtidos são positivamente surpreendentes 
quando todos estão fisicamente em um mesmo ambiente. Faça tudo 
possível para ter todos envolvidos em um mesmo lugar e interagin- 


do face a face durante a Inception 


A SALA DE GUERRA 


Mantenha a mesma sala alocada para a equipe durante o intenso 
período da Inception. Esta é comumente chamada de war room, ou, 
em português, a sala 


de guerra. 


Exemplo de uma sala de 
guerra durante uma 


Inception 





A sala deve comportar toda a equipe confortavelmente e deve ter 
uma mesa e parede com espacos limpos. Ela também deve ter flip- 


chart, cartóes, post-its coloridos, papel e canetas para todos. 


Rost-its 
coloridos... 
canetas, 
flipchant 


| o Grandes 


Uma sala de guerra preparada para uma Inception 





Asala de guerra prové o ambiente para as atividades colaborativas e 
também evita qualquer perda de tempo dado quando pessoas des- 
locam-se de um lugar para outro. Todas as informações são criadas 


e permanecem em um mesmo local. 


É importante manter as informações em uma mesma sala. Isso evita 
a documentação prematura e seu transporte. Todos podem e devem 
fazer as anotações à mão (em cartões de índice, post-its, flipcharts 
etc.) e colocá-las nas parede e mesas, de forma que as informações 


fiquem visíveis para todos. 
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POST-ITS COLORIDOS 


Faça as anotações em post-its ou cartões coloridos. Escreva e colo- 
que-os ou na mesa, ou na parede. Reúna as pessoas ao seu redor, 
fale sobre eles e, então, escreva um pouco mais. Agrupe-os. Sepa- 
re-os. Rasgue-os e escreva de novo. Faça uso de cores. Reorgani- 
ze-os. À colaboração gerada a partir de tal aparato tão simples não 


tem como ser alcançada por qualquer alternativa digital. 


Não há substituto para as ações de escrever, reescrever, agrupar ou 
rasgar post-its coloridos. Isso promove a interação entre as pessoas 
e ajuda no processo criativo de experimentação, construindo um 
caminho, sem medo de tentar, errar ou refazer. Logo que a infor- 
mação vai para o computador, ela não volta ao papel. Isso reduz a 
interação entre as pessoas, pois não há nada em cima da mesa ou 
nas paredes visíveis a todos e que possa facilmente ser rasgado, 


reagrupado ou reescrito. 


A AGENDA BURN-UP 


A agenda burn-up (em detalhes no apêndice C) ajuda com o gerencia- 
mento de tempo e escopo de um workshop de Inception. Ter a agen- 
da visível constróia confiança na gestão do tempo e no progresso das 
atividades como um todo. É uma ferramenta simples e eficaz para pla- 


nejar e facilitar o workshop e, também, para chegar direto ao ponto. 





Exemplo de uma agenda burn-up 


O eixo vertical é a quantidade de tópicos ou atividades a serem 
realizadas e é medido em unidades personalizadas para a agen- 
da específica do workshop. O eixo horizontal representa o tempo, 
normalmente medido em horas ou dias. 
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AGENDA PLANEJADA E A 
AGENDA BURN-UP 


Sugiro que utilize a agenda burn-up. Entretanto, algumas pessoas, 
especialmente as que não vão estar dedicadas ao workshop de In- 
ception, precisam ter um entendimento da semana. Por tal motivo, 
compartilho o template de agenda para esse workshop (disponível 


em http://caroli org/diretoaoponto). 


Planejamento da semana 








ALMOÇO 


Exemplo de agenda planejada 


O modelo de agenda planejada apresenta dois tipos de 
sessóes (em cores laranja e azul). que correspondem aos 


níveis de participação: stakeholders e membros ativos. 


Stakeholder é qualquer pessoa impactada pelo projeto. São 
pessoas altamente interessadas no direcionamento e resul- 
tado da Inception, mas que não têm tempo para participar 
de todas as sessões. Elas podem ser os patrocinadores, os 


usuários finais, jurídico, vendas e marketing. 


Já o membro ativo é qualquer pessoa diretamente envolvida 
pela compreensão e implementação do produto. Estas são 
as que devem participar ativamente de todas as sessões do 
workshop, podendo ser: product owners, desenvolvedores, 


testadores, gerentes de projeto e experiência do usuário. 


Note na agenda planejada que as atividades de kick-off 
e showcase do workshop estão marcadas em cor laranja, 
respectivamente no início e no final da semana. No mundo 
ideal, todos estarão presentes na sala de guerra durante a 
semana. Entretanto, raramente temos a disponibilidade de 
agenda dos stakeholders. O mínimo necessário é que eles 


participem das sessões de kick-off e showcase, nas quais 





são apresentadas as expectativas do negócio para a sema- 





na, bem como o resultado obtido pelo time dedicado ao 
workshop. Os demais dias são tomados por uma sequência 
de atividades intensas, seguidas por períodos de consoli- 


dação. As atividades a serem seguidas devem estar listadas 





na agenda burn-up. 
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PARQUE EM LOTE 


O parque em lote ajuda a arquivar momentaneamente quaisquer 
itens, ideias ou questóes que sáo levantadas durante uma atividade 
da Inception Enxuta, mas náo sáo úteis para a discussáo naquele 
momento específico. É uma ferramenta essencial para o facilitador, 
pois proporciona uma maneira educada de dizer "Sim, eu ouvi você. 


Mas essa conversa fica para depois”. 


Parking Lot (estacionamento, em inglês) é o termo comumente uti- 
lizado para tal ferramenta. Certa vez, desejando aplicá-la durante 
uma Inception, pedi para um colega escrever o termo em uma folha 
de flipchart. Ele entendeu o conceito, entretanto escreveu em por- 


tuguês: Parque em lote. Deste então tenho utilizado esta expressão. 


Aistes Sarna 
Cora mé ye 
os "A 





O facilitador deve introduzir o conceito de Parque em lote ou no 
início da Inception Enxuta, ou assim que a primeira conversa desviar 


do assunto. Escreva Parque em lote em um flipchart e coloque-o em 


uma parede na sala de guerra. Se o item em discussão ainda não 
estiver escrito em um post-it, faça-o e coloque-o no Parque em lote. 
Certifique-se de explicar brevemente o conceito da ferramenta, e 
retorne a atividade em questão. É importante ser bem assertiva com 


os participantes da Inception Enxuta sobre o Parque em lote: 


A conversa estava desviando do foco da atividade em 


questão, e por isso talitem foi para o Parque em lote. 





Todavia é igualmente importante ouvir e respeitar as opiniões, ideias 
e pensamentos dos participantes da Inception. Portanto, o Parque 


em lote deve ser utilizado conforme prometido: 


Este item está estacionado por agora; mas vamos voltar 


a ele mais tarde. 





De fato, no final de cada dia da Inception, você deve usar 10 minutos 
para rever os itens no Parque em lote. Desta forma, uma destas duas 
ações é tomada para cada item: (1) o item é removido do Parque em 
lote (o tema já foi abordado ou não precisa mais ser tratado); ou (2) 


o item permanece no Parque em lote para a próxima revisão. 


A última revisão deve acontecer no final da Inception. Nessa última 
avaliação é muito importante esclarecer todos itens remanescentes 


e compartilhar com todos o que vai acontecer com eles. 
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CHECKLIST PARA 
A INCEPTION 


A lista a seguir é projetada para auxiliar o processo de planejamento 
do workshop de Inception. Por favor, certifique-se de ter todos os 


itens programados antes de iniciar uma inception. 


Participantes selecionados e convidados (stakeholders e membros 


ativos); 
Facilitador experiente (ver o apêndice B); 


Reserva de sala (manter a mesma sala durante o período da Incep- 


tion); 
Flipchart, cartóes, post-it, papel A4 e canetas para todos; 


Coffee break. 


PRODUTO 
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Com a ajuda de uma visáo clara 
do produto, vocé pode determinar 
quais e como as primeiras pecas 
do seu quebra-cabeça do negócio 
se juntaráo. Você deve decidir so- 
bre qual característica do produto 


o caminho inicial será trilhado e 





qual será a sua estratégia de posi- 


cionamento. 


ESCREVENDO A 
VISÃO DO PRODUTO 
COLABORATIVAMENTE 


Em algum lugar entre a ideia e o lançamento, a visão do produto 
ajuda a trilhar o caminho inicial. Ela define a essência do seu valor 
de negócio e deve refletir uma mensagem clara e convincente para 
seus clientes. Essa atividade ajudará a definir colaborativamente a 


visão do produto. 


Template visáo do produto 


Para [cliente final], 

cujo [problema que precisa ser resolvido], 

o [nome do produto] 

é um [categoria do produto] 

que [benefício-chave, razão para adquiri-lo]. 
Diferentemente da [alternativa da concorrência]. 


o nosso produto [diferença-chave]. 


@-----------------------© 


A visáo do produto, foi descrita no livro Crossing the chasm: mar- 
keting and selling high-tech products to mainstream customers, de 


Geoffrey A. Moore (1999). 


COMO FUNCIONA: 


Escreva o template visáo do produto em um 
quadro branco ou flipchart de forma que seja 


visível para toda a equipe; 


@ Divida a equipe em grupos menores e solicite 
que cada um deles preencha uma lacuna se- 
paradamente (ou mais, dependendo do seu 


tamanho); 


E) Reúna o resultado de cada grupo, formando 


uma única frase. 
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Nessa atividade, é muito comum que o resultado seja uma frase 
desconexa. Logo após a execução do terceiro passo, é importante 
que a equipe trabalhe em conjunto para formar uma frase homo- 
gênea, utilizando e alterando os resultados anteriores, conforme 


necessário. 


O PRODUTO É / NÃO É / 
FAZ / NÃO FAZ 


A atividade É / Não é / Faz / Não faz ajuda a definir um produto. Por 
vezes, é mais fácil descrever algo pelo que tal coisa não é ou deixa 
de fazer. Ela busca clarificações ao indagar especificamente cada 


aspecto positivo e negativo sobre o produto ser ou fazer algo. 


PASSO A PASSO DA ATIVIDADE: 


68 Divida um quadro branco ou flipchart em 
quatro áreas (É / Não é / Faz / Não faz): 


Escreva o nome do produto em destaque aci- 
ma dos quadrantes: 
produto em post-its e colocando-os nas áre- 


as devidas; 


Leia e agrupe as notas semelhantes. 


E) Solicite que cada participante descreva o 
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Nome do produto 

O produto é [...] 

O produto náo é [...] 
O produto faz [...] 

O produto náo faz [...] 





Essa atividade ajuda a esclarecer o produto. Após isso, tipicamente, 


os participantes teráo uma visáo mais alinhada tanto sobre o que ele 
faz, quanto o que náo faz. Decisóes estratégicas podem ser clarifi- 
cadas, como: tal coisa o produto nunca vai fazer, aquela outra ainda 
náo deve fazer etc. 


Aprendi esta atividade com Rafael Sabbagh quando ele a utilizou 
para definir um dos papéis do Scrum (SABBAGH, 2013) durante um 
de seus treinamentos. 


ESCLARECENDO O OBJETIVO 


Cada membro da equipe deve compartilhar o que entende como 
objetivo para quem usa o produto e os vários pontos de vista devem 
ser discutidos para que se chegue a um consenso sobre o que é 
realmente importante. Essa atividade auxilia no levantamento e es- 


clarecimento desses objetivos. 


PASSO A PASSO DA ATIVIDADE: 


Solicite a cada membro da equipe que es- 
creva, individualmente. três respostas para a 
seguinte pergunta: *Se você tiver que resumir 
este produto em três objetivos para seus usuá- 


rios, quais seriam eles?*; 


o) Solicite aos participantes que compartilhem 
o que escreveram em um _canvas_ comum, 


agrupando-os por similaridade; 


E Solicite à equipe que reescreva os objetivos, 
agora coletivamente. Nesse momento, ficará 
claro que alguns dos elementos listados não 
são realmente objetivos do produto, devendo, 
portanto, ser descartados. Com isso, ficará ní- 


tido para a equipe qual o foco do projeto. 
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A seguir, duas fotos que mostram exemplos de produto cujos objeti- 
vos foram agrupados por similaridade. Na parte superior das fotos, 
os objetivos sáo reescritos (em post-it amarelo). Note na segunda 
foto uma contagem de votos ao lado dos objetivos. Esta foi realizada 
após reescrevé-los, pedindo a cada participante que marcasse dois 
votos nos dois principais. Assim, ficam visíveis a todos os objetivos e 
seu peso para o grupo. 





Exemplo de objetivos agrupados e com votos 


ENTENDENDO OS 
TRADE-OFFS 


Trade-off é uma troca em que você desprioriza algo para conseguir 
outro que deseja ainda mais. Um produto enxuto reflete decisões da 
equipe em relação a trade-offs. 


A atividade Entendendo os trade offs ajuda na construção e docu- 
mentacáo de um entendimento comum sobre os trade-offs do pro- 
duto enxuto. Muitas decisóes e conversas sáo baseadas em visóes 
individuais e premissas entre escolhas. Alguns exemplos: o que tem 
um valor maior, a seguranca ou a facilidade de usar? E quanto a 
escalabilidade e seguranca? E escalabilidade e facilidade de usar? 


Essa atividade promove uma conversa aberta e colaborativa sobre 


os trade offs, e os mais esclarecidos evitam desentendimentos e 


ajudam na rápida tomada de decisões. 


Exemplo de resultado: 





trade-offs do produto enxuto 
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PASSO A PASSO DA ATIVIDADE: 


Descreva todas as categorias relevantes para 
o produto em post-its (exemplo: segurança, 


usabilidade, escalabilidade); 


Coloque as categorias no quadro branco ou flip- 
chart como títulos de linhas. Em seguida, dese- 


nhe uma linha horizontal para cada categoria: 


Desenhe linhas verticais (o mesmo número de 
linhas horizontais). Escrever mais (importante) 
em cima da linha, mais à esquerda, e menos em 


cima da linha, mais à direita; 


Peça aos participantes para marcar suas iniciais 
em vários post-its e colocar um por linha. A res- 
trição é que cada coluna deve ter um com suas 
iniciais (por exemplo, apenas uma das catego- 


rias vai ser marcada como mais importante); 


Equalize os trade-offs. Com um post-it de cor 
diferente (uma tira de post-it verde na foto 
ilustrativa), faça a marcação devida para cada 
categoria de mais a menos importante. Essa 
marcação será relativamente fácil, já que são 


considerados os post-its com os votos de todos. 





Outro exemplo de resultado: trade-offs do produto enxuto 
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PERSONAS 


Para identificar efetivamente as funcionalidades de um sistema, é 
importante ter em mente seus usuários e objetivos. A maneira nor- 


malmente utilizada para representar estes usuários é por meio de 


personas (PATTON, 2010). 
Uma persona representa um usuário do sistema, descrevendo náo 
só o seu papel, mas também suas necessidades específicas. Isto cria 


uma representacáo realística, auxiliando o time a descrever funcio- 


nalidades do ponto de vista de quem interagirá com o produto final. 


QUADRANTES PARA 
IDENTIFICAR TIPOS 
DE PERSONAS 


A seguinte atividade é utilizada para descrigáo de tipos de personas. 


Ela é simples, ilustrativa, divertida e rápida. 


PASSO A PASSO DA ATIVIDADE: 


Solicite ao time que se divida em pares ou trios 
e entregue o seguinte template de personas 


para cada grupo: 
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E) Peça a cada grupo que crie uma persona, utili- 
zando o template como referência; 


O Solicite aos participantes que apresentem suas 


personas a todo o time; 


O Requisite ao time que mude os grupos e repita 
os passos de l a 3. 





Template para identificar personas (em folha de papel A4) 


Ao final da atividade, um conjunto de personas deve ter sido criado 
eos diferentes tipos de usuários do sistema devem estar descritos. 
Os stakeholders, que conhecem os objetivos do projeto, devem par- 
ticipar ativamente da atividade, auxiliando a equipe nessa criação 


e sugerindo alterações em suas descrições, conforme necessário. 
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Exemplo de personas: resultado da atividade 2 


O template apresentado foi criado por Natalia Arsand, excelente 
User eXperience designer e colega de trabalho da ThoughtWorks Brasil. 


CRIANDO MAPAS DE 
EMPATIA 


O mapa de empatia é um template visual para identifica- 
ção e visualização de uma persona. Criado originalmente 
para análise de segmentos de consumidores, ele é uma 
excelente ferramenta para classificar, explorar e entender 


os diferentes tipos de personas. 


Foi originalmente descrito por Dave Gray como um dos 
métodos da XPLANE — empresa de visual thinking fundada 
em 1993 — para compreender usuários, clientes e outros 
envolvidos no negócio. Ficou ainda mais conhecido des- 
de que foi destacado no livro Business model generation, 
de Osterwalder e Pigneur (2009), como uma ferramenta 


para descobrir insights sobre os clientes. 


O mapa apresenta quatro áreas principais, as quais pre- 


enchem a frase: 
O que eu ____ (vejo / penso / ouço / falo)? 
Além dessas quatro áreas principais, a versáo original 


apresenta mais duas: as dores (pain, em inglés) e ganhos 


(gain) para tal persona. 
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Mapa de empatia: template 


Sempre que apliquei essa atividade para identificação de personas, 
utilizei suas quatro áreas principais, Por vezes, utilizo as áreas de do- 
res e ganhos, como descrito originalmente; mas altero essas outras 
áreas, como por exemplo: o que eu faço, o que eu não faço, meus 


amigos e meus inimigos, meus hobbies etc 


PASSO A PASSO DA ATIVIDADE: 
E Decida uma persona a ser analisada, 


B Desenhe um template do mapa com a persona 
representada em seu centro; 


e Descreva as áreas para tal persona; 


(4) Repita os passos 2 e 3 para as próximas 
personas. 


Seguem alguns exemplos: 





Mapa de empatia — exemplo 1 
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Meta de empatia — exemplo 2 


FEATURES 
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Feature é a descrição de uma ação ou interação de um usuário com 
o produto. Por exemplo: imprimir nota fiscal, consultar extrato deta- 


lhado, e convidar amigos do facebook. 
A descrição de uma feature deve ser o mais simples possível. O usu- 
ário está tentando fazer uma coisa. O produto dever ter uma feature 


para isso. Que feature é essa? 


Dado que já temos as personas e os principais objetivos do produto. 


A seguinte pergunta ajuda com a descoberta de features: 


O que precisa ter no produto para que tal persona alcance tal 


objetivo? 


DESCOBRINDO 
AS FEATURES 


A seguinte atividade é utilizada para descoberta de features. Note 
que ela depende da lista de objetivos e personas que já devem ser 


artefatos adquiridos em atividades anteriores: 


PASSO A PASSO DA ATIVIDADE: 


él Solicite que a equipe coloque os objetivos em 


um canvas comum, em ordem de prioridade, da 


esquerda para direita, como títulos de colunas; 


G) Peça à equipe que coloque as personas no 


mesmo canvas, em ordem de prioridade, de 


cima para baixo, como títulos de linhas; 


E) Promova um brainstorm de features. A discus- 
são deve ser guiada para que se descubram 
quais são necessárias para atender os objetivos 
e as personas. Uma pergunta para ajudar nes- 
se processo é: O que se precisa ter no produto 


para que tal persona alcance tal objetivo”. 


A equipe deve guiar-se no canvas, repetindo essa pergunta para 
cada combinação de persona e objetivo, começando com os de 
mais alta prioridade. Desse modo, as candidatas a features de alta 


prioridade surgirão primeiro. 


O controle de tempo é essencial para todas as atividades, mas 
esta requer atenção especial. Se um grande número de objetivos 
e personas for selecionado (nos passos 1 e 2), inúmeras features 
poderão ser levantadas pela equipe. Isso será contraprodutivo e 
pode levá-la a gastar muito tempo falando sobre as que não farão 


parte dos primeiros MVPs. 


Para evitar tal cenário, é altamente recomendável que o número 
de objetivos e personas seja limitado para poucos (como três ou 


quatro principais). 
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Se estivéssemos com um orçamento muito curto e pudéssemos tra- 
balhar em apenas um objetivo, qual seria ele? 


Essa pergunta ajuda o grupo a priorizar objetivos e personas. Repita 
a questão para os objetivos, em seguida, para personas. Isso deve 


ajudar com a priorização e no foco da evolução do produto via MVPs. 


Exemplo de resultado: 
features, objetivos e 
personas, respectiva- 
mente em post-it azul, 
post-it rosa e folha de 


papel branco 


Disave“, 


y lën Exemplo de resultado: 


features, objetivos e 

personas, respecti- 

vamente em post-it 
amarelo-claro, post-it 
amarelo-escuro e folha 


de papel branco 


Embora o canvas seja semelhante a uma matriz, náo 
necessariamente haverá uma feature para cada in- 
terseção. Pode haver múltiplas features para uma 
persona alcançar um objetivo específico, assim 
como é possível haver personas que não necessi- 


tem de uma feature para determinado objetivo. 


Caso sejam identificados objetivos e features que 
não atendem as necessidades de nenhuma per- 
sona, estes devem ser descartados ou repensa- 
dos. pois o seu valor não está claramente asso- 


ciado a um usuário. 


ENTENDIMENTO TÉCNICO E 
ENTENDIMENTO DE NEGÓCIO 


Esta atividade tem o objetivo de discutir como a 
equipe se sente em relação ao entendimento técni- 
co e o entendimento de negócio para cada feature. 
A partir dela, novas notas são capturadas, e discor- 


dâncias e dúvidas ficam mais aparentes. 
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Template para a atividade 


PASSO A PASSO DA ATIVIDADE: 


Crie, em um canvas comum, um gráfico, onde 
o eixo X representa entendimento técnico 
(como fazer), e o Y, o entendimento sobre o re- 


quisito de negócio (o que fazer); 


Solicite a um membro da equipe que leia uma 
feature em voz alta e a posicione no gráfico 
de acordo com o seu entendimento sobre ela 


(técnico e de negócio); 


E) Questione a equipe se todos compartilham 
daquela opinião. Se alguém não concordar, 
ela deve discutir os requisitos e a tecnologia 
envolvidos de forma que haja um consenso 
sobre a feature. Tudo o que for mencionado e 
que ajude a alcançar uma melhor compreen- 


são deve ser anotado e anexado nela: 


O Anote na feature o nível de entendimento. Por 
exemplo, a figura a seguir mostra features em 
post-it que foram colados em index cards ver- 
des, amarelos ou vermelhos, indicando, res- 
pectivamente, um nível alto, médio ou baixo de 


entendimento: 


Para cada feature capturada anteriormente, repita os passos de 2 a 4. 
No eixo X, o objetivo é verificar o entendimento da equipe em re- 
lação aos desafios técnicos, às dependências e aos requisitos de 
infraestrutura. No eixo Y, a proposta é verificar a clareza sobre seu 


objetivo, o benefício para o negócio e o que deve ser feito. 


Seguem alguns exemplos de features categorizadas em relação ao en- 
tendimento técnico de negócio — verde, amarelo ou vermelho, respec- 


tivamente, representando níveis de entendimento alto, médio e baixo. 
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Exemplo 1 





Exemplo 2 


Ao final da atividade, as features marcadas com um index card verme- 
lho com um X representam riscos altíssimos para o projeto. Normal- 


mente, a equipe decide dividi-las em pedaços menores de trabalho. 


ESFORÇO E 
VALOR DE NEGÓCIO 


Esta atividade tem o objetivo de discutir como a equipe entende o 
esforço para fazer a feature, bem como seu valor de negócio asso- 


ciado. A partir dela, novas marcações serão feitas para a cada uma. 


Business 
Value 


Effort 
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PASSO A PASSO DA ATIVIDADE: 


Crie, em um canvas comum, um gráfico, onde 
o eixo X representa o esforço (o nível de tra- 
balho para fazer), e o Y, o entendimento sobre 
o valor de negócio (qual retorno ou economia 


isso vai trazer); 


Solicite a um membro da equipe que leia uma 
feature em voz alta e a posicione no gráfico 
de acordo com o seu entendimento sobre ela 


(esforço e valor de negócio); 


Questione a equipe se todos compartilham 
daquela opinião. Se alguém não concordar, 
ela deve discutir os requisitos e a tecnologia 
envolvidos de forma que haja um consenso 
sobre a feature. Tudo o que for mencionado e 
que ajude a alcançar uma melhor compreen- 


são deve ser anotado e anexado nela; 


Anote, na feature, o nível de esforço e o va- 
lor de negócio. Por exemplo, a figura abaixo 
mostra features em index cards, nas quais fo- 
ram adicionadas marcações de $, $$ ou $$$, 
para valor de negócio alto, muito alto e altíssi- 
mo respectivamente; bem como E, EE, ou EEE, 


para nível de esforço baixo, médio e alto; 


Para cada feature capturada anteriormente, 


repita os passos de Za 4. 


No eixo X, o objetivo é verificar o entendimento da equipe em re- 
lação à dificuldade e ao trabalho que será necessário para com- 
pletar tal feature. No eixo Y, a proposta é verificar o valor, o ROI 
(Return On Investment) da feature, uma medida do negócio sobre 


quanto vale cada uma. 


Loft 


Do 4 


vSu Ae 


MECEITA 


TUTO MS 


TOME! 
pá EM VIDEO 


CESA OS 





Exemplo de features com marcações de esforço e valor de negócio 


Alguns exemplos de features categorizadas em relação ao nível de 
esforço e valor de negócio. Note que a cor do index card representa 
os níveis de entendimento, de acordo com a atividade entendimento 


técnico versus entendimento de negócio. 
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Exemplo 1 


Exemplo 2 





Escala de valor de negócio 


As marcas $, $$ e $$$ indicam valor de negócio alto, 


valor de negócio muito alto, ou valor de negócio al- 
tíssimo, respectivamente. Quando comecei a utilizar 
esse gráfico de valor de negócio, elas foram usadas 
para indicar baixo, médio ou alto; mas, raramente, 
uma pessoa do negócio respondia que uma feature 
tinha valor de negócio baixo (ou médio). A mudanga 
na escala auxiliou para que o resultado representasse 


valor comparativo entre diferentes features. 
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FEATURES MAIS 
BEM COMPREENDIDAS 


As atividades vistas neste capítulo podem e devem ser realizadas 
em conjunto. Quer dizer, cada feature deve passar pelo gráfico 
apresentado na atividade de entendimento técnico e de negócio 
e, logo em seguida, pelo gráfico apresentado na atividade esforço 


e valor de negócio. 





Gráficos lado a lado 


Na primeira atividade, a feature recebe uma cor; na segunda, mar- 
cações de valor e esforço. À cor representa o nível de incerteza da 
feature (alto, médio ou baixo), enquanto marcações de valor de ne- 
gócio e esforço variam em uma escala de uma, duas ou três vezes 


comparativamente; por exemplo E, EE, e EEE. Tal cor e marcação 


ajudará a equipe nas atividades subsequentes para priorizar, esti- 
mar e planejar. Seguem dois exemplos de features antes e depois 


de passarem pelas atividades: 





Exemplo |: Features depois das atividades 





Exemplo 2: Features depois das atividades 


JORNADA DO 
USUÁRIO 
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A jornada do usuário descreve seu percurso por uma 
sequéncia de passos dados para alcangar um objetivo. 
Alguns desses passos representam diferentes pontos de 
contato com o produto, caracterizando a interação do 


usuário com ele. 


Seguindo uma abordagem simples e eficaz, a descrição 
do percurso começa por identificar um usuário e um ob- 
jetivo. Ações descritas em post-its demonstram os peque- 
nos passos dados no percurso para alcançar o objetivo. A 
jornada fica aparente quando eles são alinhados em uma 
ordem lógica e sequencial, representando o comporta- 


mento do cliente e fluxo das interações com o produto. 


Questionamentos, acordos e desacordos conduzirão a 
conversa para a construção da jornada. Talvez, mais de 
uma opção de jornada será levantada, por exemplo: a 
jornada otimista, a realista, a pessimista, a principal, a 
excepcional caso isso, a excepcional caso aquilo etc. As 
opções vão forçar a priorização e a definição clara do 
objetivo e, com isso, o foco em algumas delas. As prio- 


rizadas complementarão e ajudarão na busca do MVP. 


Seu nível de detalhamento não deve ser nem muito alto, 
nem muito baixo. Ao mesmo tempo que uma jornada 
proporciona um passo a passo da interação do usuá- 
rio, ela também é uma síntese; um nivel mais elevado e 
simplificado do fluxo, sem as informações redundantes 


e os detalhes mais profundos. 


DESCREVENDO JORNADAS 


Na sequéncia, veja uma foto com várias jornadas de usuários em 
uma mesma mesa. Note que as personas estáo identificadas com 
post-it azul no lado esquerdo, e as suas jornadas seguem da es- 
querda para a direita. Nessas jornadas, post-its laranjas identificam 
ações que não envolvem o sistema, enquanto os rosas apontam 
ações que o envolvem. Pequenas setas foram marcadas conectando 


um passo ao próximo. 





Várias jornadas 


À descrição de uma jornada se dá com base em uma persona. Iden- 
tifique um cenário para tal persona e descreva o passo a passo para 
alcançar um objetivo. 
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Perguntas simples ajudam com o início da sua descrição. Alguns 
exemplos: 


O Qual objetivo tal persona quer alcançar? 
O Como ela começa seu dia? 

O O que ela faz antes disso? 

O O que ela faz depois disso? 


Uma conversa, post-it e caneta: isso é o que você precisa para des- 
crever as jornadas do usuário. Sugiro escrever e rescrever, mas co- 
mece, não fique parado esperando um insight que não vem. Depois 
de ter algo descrito, você altera. Se fizer sentido, conecte alguns 
passos muito detalhados em um só, ou quebre um passo pouco 
detalhado em menores. Não há uma fórmula mágica para isso. O 


importante é que elas sejam descritas. 





Exemplo de jornada de usuário | 


Exemplo de jornada de 


usuário 2 








Exemplo de time verificando jornadas 
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Outro exemplo de time verificando jornadas 


FEATURES NAS 
JORNADAS 


As jornadas clarificam como será a iteração com 
o produto. Se vocé seguiu a ordem demonstrada 
neste livro, elas devem estar descritas (como uma 
sequência de passos) e as features disponíveis (em 
cartões avulsos). Essa atividade descreve como 
juntá-las, revalidando e verificando toda a análise 


até este momento. 


PASSO A PASSO DA ATIVIDADE: 


Coloque as jornadas principais e as features 
visíveis, se possível, lado a lado, conforme 


ilustrado na foto anterior; 


E Seguindo a jornada, busque as features 
necessárias para cada passo. À sequência 
mostra um exemplo de como as features são 


mapeadas na jornada: 


Mapeando features para uma 


jornada — momento 1 


Mapeando features para uma 


jornada — momento 2 


Mapeando features para uma 


jornada — momento 3 
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A seguir, outro exemplo em que features são adicionadas ás jorna- 
das dos usuários. Nesta sequência, a primeira foto mostra várias 
jornadas de usuários em uma mesma mesa. Note que nela as perso- 
nas estão identificadas com post-it azul no lado esquerdo, e as suas 
jornadas seguem da esquerda para a direita. Os post-its laranjas 
identificam ações que não envolvem o sistema, enquanto os rosas, 


as ações que o envolvem. 
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Foto 1 de 2: as jornadas 


Em um segundo momento, os participantes colocam nas jornadas 
as features previamente identificadas. Note na foto a seguir as jor- 
nadas, agora com as features em cartões coloridos e marcações 


identificando esforco e valor (vide o capítulo Features). 





Foto 2 de 2: as jornadas com as features 
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PLANEJANDO 
MVPS 
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Esta feature é importante? 


Sempre obtive uma resposta positiva quando fiz tal pergunta. Por 
isso, não a faço mais. À pergunta mais relevante para ajudá-lo a pla- 
nejar a ordem das features a serem criadas seria, entáo: Qual dessas 


duas é a mais prioritária? 


Dessa forma, as features são priorizadas em relação umas às outras. 
Essa pergunta é muito útil e deve ser usada; entretanto, antes é ne- 


cessário um ponto de partida. 


Previamente, você apontou o usuário mais importante, bem como 
a jornada preferencial. Logo, o melhor ponto de partida seria a pri- 
meira feature desta jornada. Talvez, haja mais de uma nela ou em 
várias que possam ser criadas ao mesmo tempo. Daí sim, em tal 
cenário, você deve perguntar qual das duas features em questão 


é prioritária. 


Felizmente, nas etapas anteriores, alguns parâmetros já foram adi- 
cionados às features, como: o valor de negócio ($, $$ ou $$$), o es- 
forço (E, EE ou EEE) e a marcação de nível de incerteza (cartão verde 
para baixo, amarelo para médio ou vermelho para alto). Eles o aju- 


darão com o seu planejamento e com as suas prioridades relativas. 


Então, qual é a combinação minima de features que devem ser dis- 
ponibilizadas para validar um pequeno conjunto de hipóteses sobre 
o negócio? Agora é a hora de visualizar e conceituar o primeiro MVP 


e seus incrementos subsequentes. 


O CANVAS MVP 


O canvas MVP ajuda a organizar e a visualizar as 
features e sua relação com os MVPs. Ele estrutu- 
ra e planeja os lançamentos do produto, além do 
primeiro produto mínimo viável. Normalmente, as 
equipes que o usam acabam se deslumbrando com 
a evolução do produto por meio de uma compre- 
ensão clara sobre as features contidas em cada 
MVP e sua ordem de liberação. 





Exemplo de resultado: canvas MVP 
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AS ONDAS NO CANVAS MVP 


Você deve planejar uma sequência 
de ondas para agrupamento das 
features de maneira a ajudá-lo a 
organizar a produção, tornando- 
-a algo fácil de se entender. Uma 
onda após a outra, em ordem. De- 
senhe-as em um flipchart ou em 


um quadro branco seu template: o 
canvas MVP. 





Template com as ondas: canvas MVP 


AS REGRAS 
PARA CADA ONDA 


Features serão adicionadas a cada onda. À seguir, confira as seis 
regras para adicioná-las, que foram definidas depois de aplicar esta 


forma de planejamento e priorização inúmeras vezes. 


Regra |: Uma onda pode conter no máximo 3 features. 
Regra 2: Uma onda não pode conter mais de uma feature em car- 
tão vermelho. 


O00 0 


Regra 3: Uma onda náo pode conter trés features, somente em car- 
tões amarelos e vermelho. 
Regra 4: À soma de esforço das features não pode ultrapassar 5 Es. 


Regra 5: A soma de valor das features não pode ser menos de 4 $s. 





Regra 6: Uma onda tem de conter no mínimo 2 features. 


A regra 1 limita o número de features que estão sendo trabalhadas 
ao mesmo tempo. Isso evita o acúmulo de features parcialmente 
completas, aumentando o foco para as poucas features priorizadas 
por onda. Já as regras 2, 3 e 4 evitam um período de trabalho dese- 
quilibrado com muita incerteza, ou muito esforço; e as 5 e 6 garan- 


tem o foco constante na entrega de alto valor para o negócio. 


CONVERGINDO 
REGRAS E JORNADAS 


Regras simples são adicionadas ao template com as ondas. Agora, 
basta buscar a primeira feature da primeira jornada. Aí você deve 
buscar a próxima. Respeitando as regras, você decide se tal feature 


entra na onda n ou n+l. 


Caso você fique em dúvida entre duas delas que respeitam as re- 


gras, basta responder a pergunta: Qual delas é mais prioritária”. 


À seguir, mostro uma sequência com duas fotos, na qual a primeira 
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mostra uma máo em busca de uma feature na mesa onde estáo 


mapeadas jornadas e features; e a segunda foto, a mesma máo co- 


locando-a no canvas MVP, respeitando as regras. 





Colocando features 


no canvas MVP 


Duplicar ou utilizar o mesmo post-it/cartáo? 


Uma feature com suas marcações está posicionada 
em uma jornada. Vocé está prestes a pegar tal car- 
táo e colocá-lo em outro template, o canvas MVP. 
Além das informações descritas nele, o seu posi- 
cionamento no template carrega mais dados, sendo 
que isso também ocorre com a feature na jornada e 


no Canvas MVP. Neste momento, você acaba per- 


guntando-se: duplico ou utilizo o mesmo cartão? 


Minha sugestão é que tire uma foto antes de qualquer 
coisa para, então, considerar a replicar o cartão, desde 
que isso não deixe a atividade mais lenta e o ambiente 


mais confuso (com inúmeros papéis coloridos). 





Adiante, uma foto típica de um time utilizando o canvas MVP. Note 
seu envolvimento e como ele posiciona-se em frente ao template. 
Nesse momento, todos estão bem alinhados em relação às prin- 
cipais jornadas e suas features (com suas marcações de incerteza, 


valor de negócio e esforço). 
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Time utilizando o 


canvas MVP 


IDENTIFICANDO MVP 
NO CANVAS MVP 


E chegado o momento de entender os incrementos e a criagáo evo- 
lutiva do seu produto. As atividades até agora clarificaram e priori- 


zaram cada aspecto dele. 


Os pequenos blocos do produto (as features) estáo ordenados logi- 
camente no canvas MVP e, além disso, vocé entende e visualiza-os 
para as jornadas do usuário. Navegando no template com suas on- 


das e features, você esclarecerá os incrementos do MVP. 


Ao final de cada onda, verifique se tal composição de features al- 


cança uma versão simples do produto que pode ser disponibilizada. 


Caso positivo, dê um nome a tal composição, escrevendo-o em um 
post-it e colocando-o sobre a linha que delimita tal onda. Depois, 


faça isso em todas as outras. 


Na sequência, seguem alguns exemplos após esse passo de identi- 
ficação de MVPs (em post-its laranja) no canvas MVP. 


Exemplos de 
MVP no canvas 
MVP 
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As ondas não terão, necessariamente, uma relação de um para 
um com os produtos mínimos viáveis. Note que este foi o caso nos 
exemplos apresentados anteriormente. O intuito é exercitar o pla- 
nejamento e o sequenciamento de features em ondas para entregar 
valor o mais rápido possível, respeitando as dependências entre as 
features e as regras do canvas MVP. 


Note o exemplo de canvas MVP na figura ilustrativa a seguir. Nela, 
temos um canvas com 2 MVPs e 13 features. O MVP | é composto 
pelas features Fl, F2, F3, F4, F5 e F6; já o MVP 2 por: F7, F8, F9, FIO, 
Fil, F12 e FI3. 





Canvas MVP ilustrativo 


CALCULANDO 
ESFORCO, 
TEMPO 

E CUSTO 
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Os incrementos de MVP e as ondas do canvas MVP 
deixam visíveis e tangíveis as entregas do produto. 
Mesmo assim, ainda precisamos definir o esforço, tem- 


po e custos associados a cada MVP. 


A sequência de atividades até este momento, bem 
como as regras do canvas MVP, geram ondas de ta- 
manho similar. Isso simplifica a estimativa do produto e 
seus MVPs, pois nos permite usar seu tamanho médio. 
Em vez de tentar detalhar todas as features em relação 
ao esforço, ao tempo e ao custo, você as utilizará ape- 


nas como amostras para entender tais parâmetros. 


DETALHANDO A 
AMOSTRA DE FEATURES 


O tamanho das ondas é parecido. Logo, escolha trés delas e use-as 
para gerar informação detalhada de esforço, tempo e custo. Três 
são suficientes para dar uma boa noção de tais parâmetros e gerar 


uma média efetiva. 


PASSO A PASSO DA ATIVIDADE: 


& Selecione trés ondas a serem detalhadas: 


Selecione uma feature de uma das trés ondas 


de amostra; 


Descreva, em outros cartóes, os pedagos me- 


nores para a feature selecionada, 


Volte ao passo 2 e selecione outra feature até 


ter detalhado todas das ondas de amostragem. 


Flow) FLAN! We 


ondas para 
amostragem 





Ondas para amostragem 
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Ao selecionar as ondas de amostragem (passo 1), lembre-se que, 
neste momento, vocé está interessado na estimativa do todo e no 
seu tamanho médio, e náo no detalhamento do trabalho em si. Por 


isso, as ondas a serem escolhidas devem prover boa combinação 





do nível de incerteza (marcados pelas cores dos cartões), bem como 


uma boa variação na soma dos níveis de esforço (marcados com Es). 


As primeiras ondas são boas candidatas, pois tal detalhamento 
será útil não apenas para estimar o todo, mas também para ajudar 
na descrição dos pedaços menores para a construção das featu- 


res iniciais do MVP. 


O pedaço menor (passo 3) deve ser algo que faz sentido para o 
time. Times de desenvolvimento de software que seguem a meto- 
dologia Scrum costumam usar histórias do usuário como tais pe- 
daços menores (SABBAGH, 2013: SCHWABER & BEEDLE, 2001: 
COHN, 2004; HELM & WILDT, 2015). Já outros times preferem 
chamá-los de tarefas e descrevê-los sem um formato predefinido. 
O mais importante é que o time esteja confortável com o deta- 
lhamento desses pedaços menores e, logo, consiga estimar seu 


tamanho e esforço. 


Seguem dois exemplos de dois times diferentes detalhando uma 
feature em pedaços menores. No primeiro exemplo, os pedaços 
menores seguem o padrão de histórias de usuário, enquanto no 


segundo, os pedaços menores são descritos como tarefas. 


ThoughWor ks q 


ES Tos Come as 

Como Waldicle En quero 

Eu Quero priorizar mua- ds manila ontomáhiea os $ 

badog ou aude com a É 
tras I ah ara ga Congo! Ñ o 

priori vação titulos 


ThoughtWorks: | 
Como Wala | 


Exemplo |: features e histórias do usuário 


pn tontação pt 
pet HS 


egvtash 


benal 
Cr dass 


Thought 
HH 
£ ALVA os Dirpol 


no TLOPLAM 


Exemplo 2: features e tarefas 
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No restante deste capítulo, vou chamar de tarefas os pedaços me- 
nores de uma feature. Durante o passo 3, faça uma marcação tanto 
no cartão da feature, quanto nos cartões das tarefas de cada uma. 
Por exemplo, marque Fl para todas tarefas da feature |, F2 para as 


da feature 2, e assim por diante. 


Nas atividades a seguir, os cartões se moverão, e tal marcação será 


utilizada para reagrupar as features a seus pedaços menores. 


As fotos a seguir apresentam alguns exemplos de features que fo- 


ram detalhadas em pedaços menores. 


Eu gostaria pote ht Ja 
NU y 
empresas toligadas eutomad - 


a re meato a andre — 


Exemplos de features e tarefas 


Ao final dessa atividade, as features selecionadas como amostra es- 


taráo detalhadas com suas várias tarefas. 


ESTIMATIVA COMPARATIVA 


Esta atividade é usada para o entendimento do esforço relativo das 


tarefas. 


PASSO A PASSO DA ATIVIDADE: 


Em uma canvas comum (tipicamente, uma mesa 
ou no chão), identifique um extremo como sen- 


do + (mais), e outro como sendo — (menos); 


E Selecione duas tarefas e faça a seguinte pergun- 
ta: Como essa tarefa compara-se (em esforço) 


com esta outra? Mais, menos ou parecido? 


@ Coloque ambas as tarefas no canvas, indican- 
do como se comparam em relação ao nivel de 
esforço. Coloque uma ao lado da outra, caso 
ambas exigirem o mesmo nível, ou uma abaixo 


da outra, caso uma requeira mais esforço; 


O Enquanto houver tarefas a serem comparadas, 
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coloque-as no canvas ao lado de uma outra e 


repita os passos 2 e 3. 


Ao final da atividade, todas as tarefas estaráo no canvas, onde po- 
dem ser compreendidas em relação ao nível de esforço e como se 


comparam umas com as outras. 


DEFININDO TAMANHOS 


Esta atividade é muito simples e essencial para ser efetiva com o 


tempo e gerar números para cálculo. 


PASSO A PASSO DA ATIVIDADE: 


Escreva em post-it os seguintes tamanhos de 


camisa: pequeno, médio, grande e extragrande: 


E) Coloque essa marcações de tamanho no can- 
vas, sendo o pequeno mais próximo à extremi- 
dade de menos esforço e o extragrande mais 


próximo à extremidade de mais esforço; 


E Defina as demarcacóes entre os tamanhos e 
reposicione as tarefas para ficar claro seu ta- 


manho. 


Exemplo de 
resultado 





No final, cada tarefa estará associada a um tamanho de camisa. 


ENTENDENDO 
CUSTO E TEMPO 


Esta atividade é essencial para gerar números para cálculo de custo 


e tempo para cada onda, bem como para todos MVPs. 


PASSO A PASSO DA ATIVIDADE: 


En Selecione uma tarefa pequena e pergunte: Quan- 
to tempo uma pessoa leva para completa-la?. 


Selecione mais duas ou três tarefas do mesmo 


tamanho e repita a pergunta; 
Faça a média do tempo e anote-a; 


Repita os passos anteriores para tarefas de 


outros tamanhos. 


Exemplo de 
resultado 
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Ao final da atividade, todas as tarefas possuiráo uma 
estimativa de tempo e custo. Por exemplo, o resultado 
mostrado na figura anterior foi obtido em uma instáncia 
dessa atividade: um dia para tarefas pequenas, trés dias 


para médias, e quatro para tarefas grandes. 


As respostas de tempo váo influenciar o resultado final 
Por isso, seja bem enfático em relação à pergunta. Se 
possível, compare com trabalhos passados, e tente en- 
tender a motivação e a capacidade das pessoas respon- 


dendo tal pergunta. 


Desenvolvedores não gostam de responder tal pergunta: 


Quanto tempo leva para uma pessoa completar 


tal tarefa? 





Por isso, é muito importante que todos estejam muito à 
vontade com a descrição da tarefa. Caso haja qualquer 
desconforto em relação a uma tarefa, reescreva-a e consi- 


dere quebrá-la em pedaços ainda menores. 


Outra forma de fazer tal pergunta é colocá-la no plural: 
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Considere um par de desenvolvedores. Um sabe 
mais do negócio, outro menos. Um mais sénior, 
outro mais júnior. Um mais experiente na tecno- 


logia, outro mais novato. Quanto tempo leva para 


um par de desenvolvedores completar tal tarefa? 





Na minha experiência, todos ficam mais à vontade dando tal res- 
posta considerando pares de desenvolvedores atuando juntos para 


completar uma tarefa. 


TIRANDO A MÉDIA 


A partir do entendimento de esforço da atividade anterior, somamos 
o tempo estimado para cada tarefa de cada feature, e com isso so- 
mamos a duração prevista por features de cada onda escolhida do 
canvas MVP. Dessa forma, chegamos a uma média de esforço para 


cada onda, definido por pessoa e por unidade de tempo. 


As duas fotos a seguir demonstram como o cálculo foi realizado 
para um time. Elas mostram, respectivamente, as ondas escolhidas 
para amostragem e o cálculo realizado para obter a média do tempo 


estimado por onda. 








Ondas para amostragem 


Note na foto anterior que as ondas 2, 3 e 4 foram selecionadas para 
amostragem. Com isso, as features detalhadas em tarefas foram: F4 
e F5 (onda 2); F5, F6 e F7 (onda 3); e F9, FIO e Fil (onda 4). 
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Flo My A la VA 


à 
AA 





Tirando a média 


Essa foto mostra o cálculo realizado para obter a média do tempo 
estimado por onda. Cada tarefa foi estimada em dias para um par de 
desenvolvedores. Nela, cada linha mostra o somatório da duração 


prevista das tarefas de uma feature. 


Realizando o somatório de tarefas por feature, e depois de features 
por onda, o time alcançou os valores de 11 dias, 11 % dias e 9 dias, 
respectivamente para as ondas 2, 3 e 4. Logo, a média usada para 


tal time foi de 11 dias para um par de desenvolvedores por onda. 


Na sequência, outro exemplo de resultado para outro time. 





Outro exemplo de resultado 


Nessa foto, a média resultante foi de 20 unidades. Note o cálculo 


em post-it rosa do lado esquerdo, de trés ondas de amostra. 


Nesse time, a unidade utilizada era um par de desenvolvedores por 
dia. Com essa informação, ficou fácil calcular o esforço, tempo e 


custo de cada onda. 
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Podemos escolher trabalhar com um par de de- 
senvolvedores e entregar uma onda de features 
em, aproximadamente, um més (ou 20 dias úteis). 


Outra opção seria dobrar o custo mensal, tendo 


dois pares de desenvolvedores entregando, apro- 


ximadamente, duas ondas mensais. 





EXEMPLO DE 
INCEPTION 
ENXUTA 
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“Gostaria de ver um exemplo completo de uma Inception Enxuta”. 
Este foi um pedido recorrente que recebi de leitores deste livro. 
Imagino que a leitura seja mais fácil para quem já participou de um 
workshop. ou de uma Inception no estilo Direto ao Ponto. Por mais 
que o livro explique os itens da receita e o passo a passo de cada 
atividade, entendo que ainda seja válido demonstrar um exemplo 
completo. É como seguir uma receita para fazer um brownie especial 
de chocolate após ter experimentado o tal brownie especial de cho- 


colate. É isto que venho compartilhar neste capítulo. 


Por motivos de confidencialidade das empresas que me contrata- 


ram para facilitar as tais Inceptions Enxutas, não posso comparti- 





lhar o resultado das atividades para os seus produtos. Muitos deles 
começaram como produtos enxutos, com seus MVPs incrementais, 
e hoje são produtos diferenciadores nos seus ramos de atuação. 
Por tal motivo, selecionei um exemplo real, bem ilustrativo, e que 
pode ser compartilhado. Este produto enxuto foi idealizado durante 
um workshop Direto Ao Ponto em uma conferência nacional. Como 
havia mais de 20 participantes, o produto foi idealizado e comparti- 


lhado entre todos os presentes. 


Como o workshop duraria 8 horas, a agenda semanal típica de 
uma Inception Enxuta foi compactada de forma a caber em poucas 
horas. À agenda burn-up foi essencial para manter todos alinha- 
dos sobre quão rápido seria o ritmo que teríamos que seguir para 


aquele evento. 


Reitero que o conteúdo e fotos que seguem é de um exemplo ilus- 


trativo realizado em um dia, portanto, provavelmente reduzido na 


quantidade de artefatos gerados: personas, jornadas, e funcionali- 
dades. O objetivo era alcangar o mínimo necessário para cada ativi- 
dade, de modo a demonstrar a técnica Direto ao Ponto, e simular o 


ambiente colaborativo de Inceptions. 


Planejamento da semana 


ALMOCO 





Exemplo de agenda planejada 


INTRODUÇÃO 


O dia começou com um quebra-gelo. Utilizei o Zip Zap Zoom. Isso 


durou menos de dez minutos e foi bastante útil para compartilhar 
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os nomes. Começamos o dia com bastante energia e dando boas 


risadas. 


KICK-OFF 


Em vez do kick off tipico, geralmente realizado por stakeholders fa- 
lando sobre o produto ou ideia a ser concebida durante a Incep- 
tion Enxuta, o Rick off do workshop de simulacáo teve outro estilo. 
Perguntei aos participantes quem tinha ideia de produto e queria 
explorá-lo como exemplo do workshop durante o dia. Trés ideias 
foram apresentadas, e em seguida todos participantes votaram em 


qual queriam utilizar. 


VISAO DO PRODUTO 


O produto mais votado era um app para peladeiros. Aquelas pes- 
soas que gostam de jogar futebol com seus amigos do trabalho, da 


academia, ou de algum grupo que esteja marcando uma pelada. 


Para (1) ajudar os três idealizadores a descrever suas ideias, (2) fo- 
mentar a participação de todos, e (3) prover uma votação com um 
bom entendimento de cada opção, utilizamos o template de visão 


do produto para cada ideia de produto, em grupos de sete pessoas. 


A seguir, uma foto de um grupo enquanto escrevia a visáo do seu 


produto. 


Escrevendo 


avisáo do 





produto 


Para os peladeiros 

Que tém dificuldade de encontrar partidas de futebol 
O easy-bola 

É um app mobile 

Que facilita encontrar jogos 


Diferentemente do boca a boca 


O nosso produto maximiza as chances do acontecimento 


das peladas 
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Este é o resultado da visão do produto para a ideia do app para pe- 
ladeiros. À seguir, veja a foto do resultado: 





PARA OS PeLhocinos Ne Pienti 


poor 


Uso | Me tem ot fi urnage De deter Jotos 


0 (PA ChSy pola 
É da Be? mot) Le 


We Frauth& Enone Telos 


N fe Lene mento DE boca-4-v0 UY 


D Nofjo (puto Mbximixfh +5 nes qe 


a 


bamtcumenso Pr Pemoar 





As seguintes atividades neste capítulo são sobre o easy-bola. Tais 
atividades ajudam com o entendimento do produto enxuto, dos 
MVPs a serem construídos para a criação e validação desta app 
mobile. 


0000 





O PRODUTO É - NÃO É 
- FAZ - NÃO FAZ 


Na sequência, foi realizada a atividade É- Não é - Faz - Não faz para 
ajudar com a definição do easy-bola. Isso ajudou a esclarecer mais 
sobre a ideia do produto, focando em MVP e eliminado um excesso 
inicial de funcionalidades. Neste momento surgiram conversas im- 


portantes como: 


Essa app será gratuita. 
Não vai ter site ou versão online. 
Geolocation é muito interessante. 


Essa app não cria times, gerencia pagamentos, ou organiza campe- 


onatos. 


Veja uma foto do resulta- 


do desta atividade: 


O easy-bola: É - Não é - Faz - 


Não faz 
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Veja a transcrigáo dos textos nos post-its da foto: 


O produto é... 


7 Pe 

e app mobile 

e multiplataforma 

e facilitador para organizar 
peladas 

e gratuito 


e gratuito 


O produto faz... 


e marca jogos (agenda) 

e agenda quadras 

e lista partidas 

e localiza peladas próximas 
e  geolocalizacáo 

e avisos sobre ocorrências 
e notifica usuários 

e rating usuario 


e guarda reputação 
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O produto não é... 


e FB, Twitter, Whatsapp 
O sie 

e site 

e nãoéchat 


e messenger (chat) 


O produto náo faz... 


e organiza jogos 

e define times por ordem de 
pedido 

e organiza jogos e times 

O cilatimes 

e gerencia pagamentos 

e pagamento online da pelada 

e não faz jogos privados 

e nao organiza campeonatos 


e Campeonatos 
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ESCLARECENDO OBJETIVOS 


Após as atividades Visão do Produto e O Produto É - Não é - Faz - Não 
faz, realizamos a atividade para esclarecer os objetivos do produto. 
Neste momento, foi solicitado a todos os participantes que compar- 
tilhassem o entendimento que tinham para os três principais obje- 
tivos do produto. Cada um escreveu três post-its. Ao recolhê-los e 
colocá-los em grupos de afinidade, foram identificados três princi- 


pais objetivos para o produto: 


Encontrar peladas 
Divulgação 
Opções de partidas 


IDENTIFICANDO 
PERSONAS 


Após um bom entendimento do produto, foi a hora de mudar o foco 
e buscar um bom entendimento em relação às personas, os usuário 
do sistema. Para isso, utilizamos o template dos quadrantes para 
identificar os tipos de personas. Com tal template, criamos apelidos 
para cada tipo, descrevemos seus respectivos perfis, suas caracte- 
rísticas comportamentais e suas necessidades específicas. Mesmo 


com o tempo curto, todos os participantes participaram de grupos 


129 


130 





que criaram personas enquanto se divertiam com suas descrições, 


apelidos e desenhos. 


Segue uma foto de um grupo de participantes descrevendo uma 


persona. 


Participantes utilizando o 
template para identificar 


personas 


Para criarem as personas, 
os 20 participantes foram 
divididos em 3 grupos 


menores. 


Cada grupo criou duas 
ou três personas, e apre- 
sentou-as aos outros. Em 


seguida, personas dupli- 


cadas (ou muito parecidas) foram descartadas, e todos participantes 


votaram nas top quatro para o produto. 


Segue a transcrição do texto da persona mais votada: o gordinho 


bom de bola 


Apelido 
Gordinho bom de bola 


Perfil 

28 anos 

casado 

jogador frustrado 
bancário 


formado 
Comportamento 


reclamáo 

competitivo 

assíduo 

exigente com a quadra 


passa horas nas redes sociais 


Necessidade 


jogar toda semana com qualquer pessoa e local 


mas procura partidas de alto nível 


jogar à noite nos fins de semana 
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DESCOBRINDO 
AS FEATURES 


ós termos evoluído no produto, objetivos e personas, foi che- 
Após t luíd produto, objeti p foi ch 

gada a hora de pensar e deixar surgir as features (funcionalidades 
previstas para o produto enxuto). Para isso, utilizamos a atividade 


Descobrindo as features. 


A foto a seguir demonstra a atividade em execução. 


Descobrindo as 





features 


Des-Cobrir. Features são descobertas. Elas já apareceram várias 
vezes em conversas anteriores. Agora realmente é o momento de 
descobri-las. 


Note que os objetivos estão no canvas como títulos de colunas; en- 


quanto as personas estão como títulos de linhas. Isso forma o can- 


vas para que as features sejam descobertas. Com isso, o facilitador 


pode promover um brainstorm sobre as features: 


O que precisa ter no sistema para que tal persona alcance tal 


objetivo? 


Com essa pergunta, a discussáo é guiada para que se descubram 
quais features sáo necessárias para atender objetivos e personas. 
Elas são anotadas em post-it e colocadas no canvas. A pergunta é 
repetida para cada combinação de persona e objetivo, com isso, 


priorizamos os principais objetivos e as principais personas. 


Segue a transcrição dos post-its de features: 


consulta de peladas com geolocation 
consulta de peladas sem geolocation 
classificação de quadras 

rankear um jogador 

detalhamento da pelada (local, horário e data) 


ranking dos jogadores (visualização) 





detalhes financeiros da pelada 
cadastro do peladeiro 


cadastro da pelada 





convidar amigo para pelada 
filtro detalhado 


módulo de notificação 


confirmação de presença 
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notificação de pelada confirmada 


notificação de pelada cancelada 


cancelar presença 


cancelar pelada 





FEATURES MAIS 
BEM COMPREENDIDAS 


As features foram descobertas, entretanto foram 
aceitas sem ressalvas, sem perder muito tempo 
entendendo-as em detalhes, fazendo anotações 
e conversando sobre incertezas, esforço e valor 
para o negócio. Entretanto, essas conversas e in- 
formações mais detalhadas são muito úteis para 
uma melhor compreensão e planejamento de cria- 
ção de produtos enxutos. As atividades e gráficos 
Entendimento técnico e entendimento de negócio e 
Esforço e valor de negócio buscam tais informações 


de forma rápida e eficiente. 
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Gráficos lado-a-lado das atividades Entendimento Técnico e Entendimento de 


Negócio e Esforço e Valor de Negócio 


Cada feature passa por cada gráfico, e com isso ganha marcações 
de nível de incerteza, esforço e valor de negócio. No gráfico à es- 
querda na foto, a feature recebe uma cor. No gráfico à direita da 
foto, a feature recebe marcações de valor e esforço. Além dessas, 
todas e quaisquer informações extras sobre a feature são escritas 
em post-it e colocadas na parte de trás do cartão da feature. Estes 
são dois exemplos de anotações: (1) usar lib da Google para geolo- 
cation, e (2) assumir que somente vai funcionar para mobile mais 
moderno. 


Segue a foto com o resultado desta atividade, agora com as features 


e suas marcações no canvas de objetivos, personas, e features. 





Features mais bem compreendidas 


Nesta foto, a cor no cartáo da feature representa o nível de incer- 
teza da feature: vermelho para um nível de incerteza alto, amarelo 
para médio e verde para baixo. Enquanto isso, marcações de valor 
de negócio e esforço variam em uma escala de uma, duas ou três 
vezes comparativamente; ou seja $, $$, $$$ para valor de negócio 
respectivamente alto, muito alto e altíssimo, e E, EE, e EEE para 
esforço respectivamente baixo, médio e alto. As cores e marcações 
nas features ajudaram os participantes nas atividades subsequen- 


tes para priorizar, estimar e planejar os MVPs. 


Segue a transcrição dos post-its de features, agora com seus ní- 


veis de incerteza, esforço e valor de negócio. 


Feature 


muito alto 


rankear um jogador médio alto 


detalhamento da pelada (local, muito alto 

horário e data) 

ranking dos jogadores (visualização) di alto 
muito alto 
alto 
altissimo 


muito alto 


muito alto 


altissimo 
altissimo 
altissimo 
altissimo 


altissimo 
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DESCREVENDO JORNADAS 


Neste momento retornamos á perspectiva das personas, agora fo- 
cando nas suas jornadas, o passo a passo realizado para alcançar 
um objetivo. Os participantes foram novamente separados em gru- 
pos. Cada grupo selecionou uma persona, e identificou os princi- 
pais cenários para tal persona alcangar seus principais objetivos. 
O passo a passo de cada um foi descrito com post-its colados em 


um flipchart. 


As seguintes perguntas ajudaram com o início da descrigáo das 


jornadas: 
Qual objetivo tal persona quer alcangar? 

Como ela começa seu dia? 

O que ela faz depois disso até alcançar seu objetivo? 
A seguir, a foto de um 
grupo descrevendo uma 
jornada enquanto com- 


para funcionalidades de 


outros apps mobile. 


Grupo descrevendo o passo 





a passo de uma jornada 


Seguem dois exemplos de jornadas: 


Gordinho bom de bola: cadastra uma pelada 


OO Nn OUAU N 


O 


acorda cedo para o trabalho 

exagera no café da manhá 

chega ao trabalho ás 9:00 am 

durante uma reunião decide fazer alguma atividade física 

no almoço convence um amigo do trabalho a jogar futebol no fim do dia 
liga e reserva uma quadra 

abre o easy-bola 

cadastra a pelada para 8:00 pm naquele mesmo dia 

coloca informação da quadra 


envia convite para os amigos 


Amigo do trampo: aceita convite para uma pelada 


1. 


O o NO ME ON 


O 


acorda atrasado para o trabalho 

come uma barra de cereal no metró 

chega no trabalho as 9:30 am 

vai para a academia na hora do almoco 

durante uma reunião, recebe uma notificação do easy-bola 
verifica as informacóes da pelada 

verifica a classificação da quadra 

confirma sua presença na pelada 

sai da reunião para outra reunião 


às 514 pm recebe a confirmação da pelada 
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FEATURES NAS JORNADAS 


Note que alguns dos passos das jornadas descritas representam di- 
ferentes pontos de contato com o produto, caracterizando a intera- 
cáo do usuário com ele. Este é o momento de verificar toda a análise 
até aqui, comparando esses pontos de contato com o produto com 


as features e suas informações. 


As foto a seguir mostra duas ações: (1) a busca do cartão de feature 


da parede, e (2) a sua colocação junto ao passo de uma jornada. 





Colocando a feature no passo de uma jornada 


Note na foto a seguir as jornadas, agora com as features em cartões 


coloridos e marcações identificando esforço e valor. 


As jornadas, agora com as 


features 





Segue o exemplo de jornada anterior, agora com features em alguns 
passos. 


Amigo do trampo: aceita convite para uma pelada 


Passo Feature 
acorda atrasado para o trabalho 

come uma barra de cereal no metrô 
chega ao trabalho às 9:30 am 

vai para a academia na hora do almoço 


durante uma reunião, recebe uma módulo de notificação 


notificação do easy-bola 
verifica as informações da pelada detalhamento da pelada 
(local, horário e data) 


verifica a classificação da quadra 


classificação de quadras 


confirma sua presença na pelada confirmação de presença 


sai da reunião para outra reunião 


às 5:14 pm recebe a confirmação da pelada | notificação de pelada confirmada 
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O CANVAS MVP 


Enfim, chegamos ao ápice da Inception Enxuta: o canvas MVP. Este 
é o momento em que toda a análise até o momento (produto, perso- 
nas, features e jornadas) é colocada à prova perante um canvas de 
regras simples e essenciais para organizar e visualizar as features e 


sua relação com os MVPs. 


Como facilitador, descrevi as regras do canvas MVP, e deixei os par- 
ticipantes à vontade para organizar as features no canvas. À foto a 


seguir mostra todos participantes envolvidos buscando features nas 


jornadas e colocando-as no canvas. 





Buscando features das jornadas para o canvas MVP 


Enquanto os participantes escolhiam e ordenavam as features no 
canvas MVP, escrevi em alguns post-its: MVPI, MVP2, MVP3, e as- 
sim sucessivamente. Pedi que eles verificassem quando uma com- 
posição de features alcançava uma versão simples do produto que 
poderia ser disponibilizada. Caso positivo, um post-it era colocado 
ao lado direito do flipchart identificando as features de um MVP. 


Veja a foto com o resultado do canvas MVP: 


M VP CANVAS 


É e 








O canvas MVP do easy-bola 
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Segue a transcrigáo do canvas MVP do easy-bola apresentado na 


foto, com seus MVPs identificados e suas respectivas features. 


Feature 


cadastro da pelada 
cadastro do peladeiro 


consulta de peladas sem geolocation 


confirmação de presença 

detalhamento da pelada (local, horário e data) 
cancelar presença 

cancelar pelada 

módulo de notificação 

notificação de pelada confirmada 

notificação de pelada cancelada 


detalhes financeiros da pelada 


[cancelar presenga | 22 
[cancelar pelada 32 
módulo de notificagáo | 3 
notificação de pelada confirmada | 3 | 
notificação de pelada cancelada | 3 | 
detalhes financeiros da pelada | 3 | 
convidar amigo para pelada | o o 4 


convidar amigo para pelada 





ranking dos jogadores (visualização) 
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GLOSSÁRIO 
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Segue uma breve lista de termos utilizados neste livro. Cada um dos 
conceitos é explorado em detalhes nos capítulos. Entretanto, julgo ne- 
cessário um esclarecimento em ámbito geral para esses termos desde 


o início. 


Essa lista deve estar visível durante o workshop de Inception. Sugiro 


que imprima esse glossário e coloque-o na parede da sala de guerra. 


MVP 


O produto mínimo viável - em inglés, Minimum Viable Product 
(MVP) — é a versão mais simples de um produto que pode ser dis- 
ponibilizada para o negócio. Ele determina quais são as funciona- 
lidades mais essenciais para que se tenha o mínimo de produto 
funcional que possa agregar valor para o negócio (produto míni- 
mo) e que possa ser efetivamente utilizado e validado pelo usuário 


final (produto viável. 


VISÃO DO PRODUTO 


A visão do produto é uma breve descrição de para onde você quer 


levar sua ideia do produto. 


OBJETIVOS 


Um objetivo é um resultado desejado previsto para o produto. Com- 
preender os objetivos do produto serve como uma ferramenta eficaz 
para estabelecer um acordo do que ele deve ter para cumprir a visáo 


do produto. 


PERSONAS 


Uma persona representa um usuário do sistema, descrevendo náo 
só o seu papel, mas também suas características e necessidades 
específicas. Isto cria uma representação realística de usuários, au- 
xiliando o time a descrever funcionalidades do ponto de vista de 


quem interagirá com o produto final. 


FEATURE 


Feature é um agrupamento de funcionalidades semelhantes. Isso 
o ajuda com a compreensão sobre o requisito como um todo, bem 
como das suas partes menores e complementares. O entendimen- 
to de feature variará de time para time. O importante é que tal 


agrupamento faça sentido para sua equipe e que estejam alinha- 
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dos com os objetivos do produto. 


ENTENDIMENTO TÉCNICO DA FEATURE 


O entendimento da feature de acordo com os desafios técnicos e 
os requisitos de infraestrutura. Se ao responder: Vocé já fez isso 
antes? Vocé sabe como fazé-lo?, vocé obtiver uma resposta posi- 


tiva bem firme, isso indica elevado nível de entendimento técnico. 


ENTENDIMENTO DE NEGÓCIO DA 
FEATURE 


A clareza do objetivo da feature, o benefício para o negócio e o 
que deve ser feito. O que fazer? Uma resposta direta e clara indica 


um alto nível de concordância. 


NÍVEL DE INCERTEZA DA FEATURE 


O nível de incerteza da feature refere-se ao grau em que ela é in- 
certa, a partir do ponto de vista do entendimento de negócio e do 
entendimento técnico. Isso é indicado pela cor do cartão de índice: 
verde, amarelo ou rosa, indicando níveis baixo. médio ou alto de 


incerteza, respectivamente. 


ESFORÇO DA FEATURE 


O nível do trabalho que precisa ser feito para a feature. O entendi- 
mento da equipe de acordo com a dificuldade e o trabalho que vai 


ser necessário para completá-la. 


VALOR DO NEGÓCIO DA FEATURE 


O valor de negócio associado a feature; uma medida do negócio 
sobre o valor previsto para ela. Qual é o retorno no investimento 
- ROI (Return On Investment) - ou a economia que a feature vai 


trazer? A resposta deve variar entre alto, muito alto ou altíssimo. 


JORNADA 


A jornada do usuário descreve o seu percurso por uma sequéncia 
de passos dados para alcangar um objetivo. Alguns desses passos 
representam diferentes pontos de contato com o produto, caracte- 


rizando sua interação com ele. 
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FACILITADOR 
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NÍVEIS DE COMPETÉNCIA 


Este livro oferece uma receita: uma sequéncia de atividades a serem 
seguidas para alcangar a compreensáo e o planejamento para cons- 
truir o MVP de um produto. Assim como um livro de receitas de co- 
zinha, isso depende do domínio de um chef. Em outras palavras, sua 


execução está nas mãos do nosso chef, o facilitador da Inception. 


A figura a seguir identifica 6 níveis de competência para o facilitador 
de Inception. Essa classificagáo serve para alinhar as expectativas, 
mostrar a importáncia da capacidade do facilitador em aplicar as 
técnicas descritas neste livro e identificar o nível do facilitador atri- 


buído para uma Inception 





Facilitador iniciante: pessoas que estáo parti- 
cipando do workshop Inception pela primeira 


vez; 


Facilitador intermediário: pessoas que já par- 
ticiparam, mas ainda não facilitaram nenhuma 


atividade durante um workshop Inception: 


Facilitador aprendiz: pessoas que já participa- 
ram e facilitaram uma ou mais das atividades 


realizadas em workshops; 


Facilitador: pessoas que já facilitaram um 


workshop e sentem-se seguras para fazé-lo; 


Facilitador avançado: pessoas que já facilita- 
ram pelo menos cinco workshops Inception e 
sentem-se seguras para serem coachs de facili- 


tadores aprendizes; 


Facilitador evangelista: pessoas que já facilita- 
ram mais de dez e, atualmente, estão compar- 
tilhando as técnicas para o público interessado 


em workshops Inception. 
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AGENDA 
BURN-UP 


A agenda burn-up ajuda com o gerenciamento de tempo e escopo 
de uma Inception. Ter a agenda visível a todos constrói a confiança 
na gestáo de tempo e no progresso das atividades. Uma ferramen- 
ta simples e eficaz para planejar e facilitar a Inception, e chegar 
direto ao ponto. 


Elas surgiram em intensos workshops de brainstorming. como In- 
ceptions e sessões de ideações. Mesmo que esses workshops re- 
alizem brainstorming de ampla discussão, normalmente eles têm 
um limite de tempo e devem cobrir vários tópicos e atividades para 
conseguir o resultado desejado. 





Agenda burn-up às 10:50 Agenda burn-up ao meio-dia 


Essa sequéncia de fotos mostra um exemplo de agenda burn-up em 
momentos diferentes. Comegando ás 8:00 am, quando a agenda 
foi criada, com instantáneos ás 9:20, ás 10:50 e ao meio-dia, no 


término da Inception. 


OS EIXOS DA AGENDA 


O eixo vertical é a quantidade de tópicos ou atividades a serem 
realizadas. Ele é medido em unidades personalizadas para a agen- 
da específica do workshop. Já o horizontal representa o tempo, 


normalmente medido em horas ou dias. 








Os eixos da agenda 
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OS TÓPICOS DA AGENDA 


Os tópicos e atividades a serem realizadas devem ser agrupados de 
forma que suas durações sejam semelhantes. Por exemplo, se sua 
agenda tem 5 tópicos e você espera que os tópicos 1 e 2 levem meia 
hora cada, os 3 e 4 levem uma hora e o 5 leve duas horas, então 


você deve considerar ter os tópicos agrupados da seguinte forma: 


ópico le 2 
Tópico 3 
ópico 4 
Tópico 51 








Tópico 5.2 


O-=----------0 


Note que, dessa forma, cada agrupamento tem uma expectativa 
de duração semelhante. Outro aspecto importante é que eles si- 
gam uma ordem cronológica: primeiro vamos cobrir isso, depois 
aquilo, e assim por diante. Sua sequência e atividade devem ser 


claramente definidas. 


OS INTERVALOS DE 
TEMPO 


Os intervalos de tempo no eixo horizontal devem ser simétricos, co- 


meçando no início da Inception e terminando no seu final esperado. 
Nos exemplos de agenda burn-up, tal intervalo é de meia hora. Sua 
unidade de tempo (minutos, horas ou dias) deve estar relacionada à 


duração esperada para os tópicos e suas atividades. 


Considere que você está construindo uma agenda para um 
workshop de 5 dias com 10 tópicos. Usar intervalos de tempo com 
base em horas seria muito pequeno. Nesse caso, intervalos de um 


ou meio dia seria mais apropriado. 


A LINHA DE ESCOPO 


Uma informação importante da agenda burn-up é a linha de esco- 
po: a linha horizontal acima do último tópico planejado. Ela define 
claramente se e quando novos tópicos foram adicionados ou remo- 
vidos durante a Inception. Ela também permite que você visualize a 
interseção dessa linha horizontal para a vertical, que representa o 


fim do workshop. 


Tudo em discussão deve ser um tópico. Se novos temas surgem, eles 
devem ser adicionados à lista de tópicos, e a linha de escopo deve 
ser ajustada. Dessa forma, a nova linha permite identificar facilmen- 
te quando eles estão sendo adicionados. o que afetará o tempo de 


conclusão da Inception. 


O ato de adicionar um novo tópico é um sinal importante de que o 
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tempo restante do workshop deve ser repensado. A linha de escopo 
também rastreia onde temas estáo sendo removidos para cumprir 
um prazo fixo. Novamente, é importante entender como a remoção 
de um tópico da agenda afetará os outros, e é algo que precisa e 


deve ser claramente discutido com todos. 


O RITMO DA INCEPTION 


A vantagem da agenda burn-up é a visão compartilhada do que 
deve ser alcançado. Isto fica claramente visível ao se traçar uma li- 
nha horizontal de escopo e uma vertical do fim da Inception. Sua 


interseção representa o resultado esperado. 


e R 
AN 


o Y 


e 
- 


ql ee 
7 A 


Target 


dd 


Time marks 


O ritmo planejado 


Ao desenharmos uma linha diagonal, a partir do ponto de partida 


(onde os eixos encontram-se) para o resultado esperado, vocé tem 


uma indicação clara do ritmo do workshop. Na figura, esse ritmo 


está representado como a linha diagonal (planejado). 


VERIFICANDO 
O PROGRESSO 


De tempos em tempos, você deve verificar a quantidade de tópicos 
abordados e a quantidade total de tópicos planejados. A distância 
entre as linhas horizontais, marcando o tópico atualmente em dis- 
cussão e o último a ser discutido, é a indicação da quantidade de 


tópicos restantes. 


Topics covered. 
| 


| | 
| "si 
| 


Duas 





linhas 
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Quando as duas linhas se encontram, a agenda planejada estará 
completa. A distância entre elas é uma medida poderosa de quão 


perto você está de completar a agenda planejada. 


Verificar regularmente o progresso é uma parte importante da ges- 
tão do tempo. Há dois movimentos básicos para os post-its e ambos 


são horizontais: 


O tempo mudou: o post-it com uma grande 
seta que representa a hora atual deve ser mo- 
vido para a direita até a posição que represen- 


taa hora atual: 


ES A discussão sobre um tópico da agenda termi- 
nou; o respectivo post-it deve ser movido para 


a direita para a hora atual 


Esse mecanismo de movimento dos post-its permite identificar, de 
imediato, um desvio na duração esperada para os tópicos da agen- 
da. Assim que constatado, esse problema deve ser discutido e ações 
corretivas devem ser tomadas ainda em um estágio inicial, e não 


quando for tarde demais. 


FAZENDO ESCOLHAS 


Considere o instantâneo da agenda burn-up representado na próxi- 


ma imagem. Sáo 10:00 horas, o meio da Inception, e apenas 4 de 10 


tópicos foram discutidos. O burn-up deixa isso muito claro. 


Scope line 


s covered 


pao 





O ritmo planejado versus atual 


Desenhe uma linha a partir do ponto de partida (onde os eixos se 
encontram) até o último tema abordado, e, em seguida, estenda-a 
até alcançar a linha de fim do workshop. Ela representa o ritmo real 
e, a partir dela, o planejamento da agenda é questionado. O que fa- 
zer agora? Aceitar o ritmo atual e reduzir o escopo (remover tópicos 
da Inception)? Adicionar mais tempo ou acelerar o ritmo para os 


próximos tópicos? 
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ATIVIDADES 
QUEBRA-GELO 
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Quebra-gelo são atividades que servem para aquecer e promover 
a interação do grupo. São um ótimo começo para qualquer reunião 
de equipe, e muito valiosos para fases iniciais de formação de times 
e Inceptions Enxutas. Uma atividade, chamada Paulo Pontual, já foi 


demonstrada no capítulo 2: Inception Enxuta. 
Este apêncide traz mais nove atividades, completando uma dezena 
de atividades quebra-gelo para sua Inception Enxuta. Tais atividades 


foram cedidas do site e livro Fun Retrospectives [CAROLI e CAETA- 
NO, 2014]. 


LOCALIZAÇÃO GEOGRÁFICA 


Esta atividade é ótima para quebrar o gelo e também ajuda os mem- 


bros da equipe a saberem um pouco sobre cada um. 


COMO FUNCIONA: 


CD Explique aos participantes que cada um será 
uma localização geográfica (por exemplo, seu 


país, cidade ou bairro); 


© Mostre onde é o Norte e o Sul na sala; 


é Peça a cada participante para ir para onde ele 


se localiza, fazendo, um mapa o mais realista 


possível; 


Depois que todos estiverem em seus lugares, 
peça a um voluntário desenhar um mapa re- 


presentando a sala. 





Desenho ilustrativo: localização geográfica 
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TELEFONE VISUAL 


Telefone visual é um ótimo estímulo para deixar todos engajados e 


promover uma discussão sobre comunicação e suas interpretações. 


COMO FUNCIONA: 


Divida o grupo maior em conjuntos de três pes- 


soas (um ou dois grupos podem ter 4 pessoas); 


Coloque três post-its e uma caneta na frente de 


cada um; 


Peça para todo mundo escrever uma frase (no 
post-it) e, então, coloque um post-it em branco 
em cima do primeiro (neste ponto, apenas o au- 


tor da frase a conhece); 


Todo mundo passa o post-it para o lado, no 


sentido horário: 


Cada um lê a frase do post-it à sua frente e 
cria um desenho no post-it em branco, repre- 


sentando-a: 


Todo mundo passa o post-it para o lado no sen- 


tido horário: 


Em um novo post-it, cada pessoa escreve uma 
frase sobre o desenho a sua frente e coloca em 
cima do conjunto de post-its (agora, este tem 
trés: um com a frase original, um com o dese- 


nho e um com a nova frase); 


E) Todos passam os post-its para o lado no sen- 
tido horário (para os grupos de três pessoas, o 
conjunto deve parar na frente do autor da pri- 


meira frase); 


O Abra o conjunto de post-its para que todos pos- 


sam ver as frases e seus desenhos respectivos. 





Desenho ilustrativo: telefone visual 
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Normalmente, os participantes riem e divertem-se comparando os 


desenhos e as frases. 


Essa é um ótima atividade com uma mensagem sutil sobre co- 
municação (visual e escrita), contexto e interpretações. Ela é uma 
adaptação de uma atividade que aprendemos em um workshop UX 
(User eXperience), dos meus queridos amigos Natalia Arsand, Glau- 


ber Ramos, Juliana Dorneles e Gabriel Albo. Eles a aprenderam no 





workshop da IDEO, Human Centered Design. 


UM DOIS PING 
QUATRO PONG 


Esta é uma atividade curta para começar uma reunião em um bom 


clima e deixar os participantes engajados. 


COMO FUNCIONA: 


é Peça para os participantes formarem um círculo; 


Os participantes devem decidir em que senti- 


do seguir (horário ou anti-horário): 


E) Alguém começa dizendo qualquer número po- 
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sitivo que náo seja múltiplo de 3 ou 5: 


A próxima pessoa, seguindo a direção deci- 
dida por todos, mentalmente adiciona | ao 


número. Então: 
O Seonúmero não é múltiplo de 3 ou 5: ela diz o número. 


O Seo número é múltiplo de 3: diz ping e bate palma. 
O Se o número é múltiplo de 5: diz pong e pula. 


Desenho ilustrativo: 





um dois pins quatro pong 
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Para grandes grupos, é recomendado remover uma pessoa dele 
caso ela erre ou acuse alguém erroneamente. Logo, todos estaráo 


rindo e torcendo para os que permanecerem no círculo. 


FORMANDO TRIÂNGULOS 


Esta atividade é um ótimo _energizer_ com uma mensagem valiosa, 
sendo muito útil para começar uma conversa sobre equipes auto- 


-organizadas. Ela é divida em duas partes. 


COMO FUNCIONA: 


Primeira parte 


Peça aos membros do grupo para andarem in- 


dividualmente em uma direção aleatória; 


Depois de um tempo. diga a palavra mágica 
“triángulo”. cada membro do grupo terá que 
achar outras duas pessoas e formar um triân- 
gulo equilátero (cada um é um vértice do tri- 
ângulo e deve apontar o braço em direção às 
outras duas pessoas, representando os outros 
vértices. Cada pessoa é um vértice de apenas 


um triângulo); 
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Cronometre quanto tempo levou para o grupo 


formar os triángulos. 





Desenho ilustrativo: formando triángulos 


Segunda parte 


E Selecione uma pessoa para ser o orientador 
do grupo; 


Peca aos membros do grupo para andar em 


uma diregáo qualquer; 


© Depois de um tempo, diga a palavra magica 


“triángulo”: o orientador do grupo tem de for- 


mar triángulos equiláteros comtodos os mem- 
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bros do grupo (incluindo ele mesmo em um 


dos triângulos); 


Cronometre quanto tempo levou para o grupo 


formar os triângulos. 


A primeira parte mostra um grupo auto-organizado; a segunda, um 


grupo guiado por um organizador. 


Normalmente, a formação do triângulo auto-organizado é mais 
rápida que sua contrapartida, e a equipe sente-se mais engajada 


na atividade. 


Ela foi feita por Heitor Roriz (https://twitter.com/hroriz), um co- 
lega e coach de equipes. Deixo aqui meus parabéns a ele por 
aplicar uma atividade divertida que ajuda a promover a discussão 
sobre um conceito essencial para equipes ágeis bem-sucedidas: 


a auto-organização. 


ZIP ZAP ZOOM 


Este é um bom inicio para reuniões, especialmente para novas equi- 
pes. Traz energia para a sala e a dinámica da atividade ajuda os 


participantes a lembrar os nomes uns dos outros. 


COMO FUNCIONA: 


é) Peça ao time para formar um círculo e a cada 
participante para fechar suas mãos, enquanto 


apontam com seus dedos indicadores. 


é Explique os comandos Zip, Zap e Zoom. 


ED Peça para um participante fazer o primeiro 


movimento, dizendo um dos comandos ver- 
bais e escolhendo a direção inicial (horário ou 


anti-horário). 
Os comandos: 


O Zip: aponte para a pessoa exatamente ao seu lado, mantendo a di- 


reção anterior. 


O Zap: aponte para a pessoa exatamente ao seu lado, mudando a di- 


reção anterior. 


O Zoom: aponte para qualquer pessoa no círculo, dizendo seu nome. O 


receptor deve decidir a direção para o próximo movimento na sua vez. 
Quando um participante executar um comando errado, um que não 


existe ou apontar para a direção errada em um comando zip/zap, 


ele deve ser removido do círculo. 
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Desenho ilustrativo: zip zap zoom 


Essa atividade náo é apenas um bom estímulo, mas também dá aos 


participantes foco e os ajuda a lembrar os nomes uns dos outros. 


DESEMBARACEM-SE 


Desembaracem-se é um ótimo estímulo para movimentar as pes- 
soas e passa uma mensagem muito interessante sobre achar uma 


solução em uma situação complicada. 
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COMO FUNCIONA: 


Peça ao grupo para formar um círculo (o tama- 
nho do grupo tem de ser mais que seis pessoas. 
Para grupos muito grandes, separe em meno- 


res, com aproximadamente 12 pessoas cada); 


Peca para todo mundo colocar as máos para 


cima; 


Dê as instruções para se embaraçarem: Com 


sua máo direita, pegue a máo esquerda de al- 
guém. Com sua mão esquerda, pegue a mão di- 
reita de alguém. Você não pode pegar a mão de 


pessoas ao seu lado. 


Peça ao grupo para se desembaraçar sem sol- 


tar as mãos e tentar formar um círculo. 





Desenho ilustrativo: desembaracem-se 
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O grupo vai pular as máos, alternar-se e achar uma saída, seja for- 
mando um ou mais círculos. Às vezes, é impossível desembaraçar- 
-se. Neste cenário, peça ao grupo para remover uma pessoa. As 
mãos que ficarem livres devem conectar-se coma pessoa remanes- 


cente no grupo embaraçado. 


PEÇAS COMPLEXAS 


Peças complexas é um ótimo _energizer_ para fazer as pessoas in- 
teragirem enquanto conversam sobre sistemas complexos e peças 


interconectadas. 


COMO FUNCIONA: 
ED Todos ficam em pé e andando. 
© Cada pessoa pensa em duas outras pessoas. 
Sem dizer nomes, cada pessoa deve ficar 
igualmente distante das duas pessoas em 


quem pensou. Isso deve levar um minuto, en- 


quanto elas se movem. 


E Depois que todos pararem, peça para a pes- 


soa mais alta do grupo ir a um canto da sala. 


Peca para todos encontrarem suas distáncias 


iguais de novo. 





Desenho ilustrativo: peças complexas 


Aprendi esta atividade com Bethlem Migot. Ela a usava como ener- 
gizer durante um workshop de análise. A atividade deixou todos 
energizados antes de ela ter uma breve conversa sobre sistemas 
complexos, mudanças e requerimentos interconectados. Vale apon- 


tar que ela funciona melhor em grupos de dez a trinta pessoas. 
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COSTAS COM COSTAS 


Costas com Costas é uma atividade enérgica e divertida que passa 


uma mensagem forte e simples sobre trabalho colaborativo. 


COMO FUNCIONA: 


& Diga para os participantes acharem um par 


com altura e peso parecidos como seu. 


Peca para todos sentarem-se no chao, com os 


pares um de costas para o outro. 


Peça para os pares entrelaçarem os braços, 


enquanto ficam de costas um para o outro. 


Diga para todos que o objetivo é ficar em pé, 


mantendo braços e costas juntos. 


Desenho ilustrativo: 


costas com costas 





Essa atividade é muito divertida e fará as pessoas rirem. Normal- 
mente, poucos pares conseguiráo ficar em pé rapidamente, en- 
quanto outros teráo dificuldade. Considere náo fazé-la se vocé 
perceber que algum participante náo é capaz de ficar em pé, ou 


que náo gostará de sentar-se no cháo. 


ENCONTRE SEU PAR 


Este é um energizer muito divertido para mover as pessoas e fazé- 


-las rir. 


COMO FUNCIONA: 


E) Conte o número de participantes (um número 
par de participantes é necessário, entáo deci- 


da se participará ou náo baseando-se nisso). 


E Divida o número de participantes em dois para 
decidir quantos animais existiráo (se forem 20 
participantes, entáo existiráo 10 animais dife- 


rentes). 


é Para cada animal, escreva o nome em dois 


post-its. 
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Distribua os post-its para os participantes e 


diga a eles não os mostrarem para ninguém. 
Peça para todo mundo andar pela sala. 


Diga a todos para cobrirem os olhos com as 


mãos, fazerem o som do animal e tentarem 


descobrir onde está seu par. 


Desenho ilustrativo: encontre seu par 


Aprendi essa atividade com Bethelm Migot. Confesso que demorei 
um pouco para usá-la, mas decidi tentar depois de vé-la sendo usa- 
da várias vezes e, então, perceber como as pessoas gostavam. Ape- 
nas recomendo cuidado com diferenças culturais e tenha certeza 


que os participantes estão acostumados com energizers. 
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